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allows languages to send, receive and manipulate structures 
defined by other languages. Structurally, the present inven- 
tion includes a preprocessor and a runtime library. The 
preprocessor accepts, as input, source code written in a 
high-level language, such as C or C++. The preprocessor 
produces, as output, a series of Java classes. Each Java class 
describes a structure defined in the input source code. Java 
programs use the descriptions produced by the preprocessor 
to send, receive and manipulate structures the structures 
defined in the input source code. 
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Fig. 3 

206' 

typedef struct ^ 

302a-^_x int x; 
302b--^ int y; 
302c^^ int z; 

} Coor^inate3D; 

300 



Fig. 4 

210* 

Coordinate3D 4po X 

•/ <; 

public class Coordinate3D 
{ 

402a~w public final static int X = 0; 
402b^^ public final static int Y = 4; 
402c public final static int Z = 8; 

I* length of Coordinate3D */ 
402d~\_^ public final static int structlen = 12; 

}; 
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Fig. 5 



206' 



typedef struct 
{ 

500a~v_^ Coordinate3D Start; 
500b-\^ Coordinate3D Stop; 
} Trip; 



600a-^s^public final static int Start$X = 0; 
600b-\^public final static int Start$Y = 4; 
600c-\^ public final static int Start$Z = 8; 
600d~\^ public final static int Stop$X = 12; 
600e~^^ public final static int Stop$Y = 16; 
600f—^ public final static int Stop$Z = 20; 

I* length of Trip*/ 
eOOg-N^ public final static int structlen = 24; 



Fig. 6 
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public class Trip 
{ 
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Fig. 7 



206'" 



typedef struct 
{ 

700a~v^Coordinate3D Start{10]; 

700b-v_^Coordinate3D Stop[5]; 
}Trip; 



Trip / 

7 

public class Trip 
{ 

800a~^^ public final static int Start$X[10] = {0, 12, 24, 36, 48, 60, 72, 84, 96, 108}; 
800b~^ public final static int Start$Y{10] = {4, 16, 28, 40, 52, 64, 76, 88, 100, 112}; 
800c public final static int Start$Z[10] = {8, 20. 32, 44, 56, 68, 80. 92, 104, 116}; 
800d-*s_^ public final static int Stop$X[5] = {120, 132, 144, 156, 168}; 
800e-v^ public final static int Stop$Y[5] = {124, 136, 148, 160, 172}; 
800f~v^ public final static int Stop$Z[5] = {128, 140, 152, 164, 176}; 

I* length of Trip 7 
800g-\^public final static int structlen = 180; 



Fig. 8 
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1 002 byte Q buffer = new byte[Coordinate3D.structlen]; 



1 004 jn.read (buffer, 0, Coordinate3D.structlen); 



1006-^^inbuf received_structure = new inbuf (buffer); 

1008^s_^ int X = received_structure.readlnt (Coordinate3D.X); 
1010-x^ int Y = received_structure.readlnt (Coordinate3D.Y); 
1012-\_xint Z = received_structure.readlnt (Coordinate3D.Z); 
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METHOD FOR INPUT AND OUTPUT OF sor maintains this correspondence by naming each class to 

STRUCTURES FOR THE JAVA LANGUAGE match the name of the corresponding structure definition. 

Each class functions as a description of the structure that it 

FIELD OF THE INVENTION named after. To perform this function, each class includes 

5 a series of static integers. One of these static integers is 

The present invention relates generally to interprocess preferably given the reserved name strucden. The strucden 

communication between processes created that use different static integer included in a class is initialized to be equal to 

programming languages. More specifically, the present me size of structure that the class is named after. Each of the 

invention includes a method and apparatus for input, output remaining static integers included in a class is named after 

and manipulation of structures within processes created 1Q one of the elements included in the structure that the class is 

using languages that do not support structures. named after. Each of these static integers is initialized to 

equal the byte offset of the structure element that it is named 

BACKGROUND OF THE INVENTION after. 

t 4 . 4 . T1 w, . , . r The classes are emitted by the preprocessor function as 

Interprocess communication, or IPC, is a general term for , . . _ . 4 4 J . . \ . \ . ^ ~ 

. u ■ *u . ii . u * f ,c descriptions of the structures included in the C or C++ input 

techniques that allow software processes to exchange lnfor- 15 C1 A r . . , . . , . ... T r 

„ , . . r *• file. As classes, these descriptions are available withm Java 

mation. By exchangmg information, software processes *u * • j 

* : r * , w-» » || v - r ™ programs. In this way, the present invention provides a 

cooperate to perform tasks. Functionally, the use of IPC r J" . , *! . * . Jr \ ^ 

- r « n ■% . , method for generating descnptions of C and C++ structures 

offers a number of advantages over more traditional mono- ... , to . 4 . & /. T 

. , i ™_ • 4 • « with descriptions available within Java programs, 

hthic programming models. These advantages include ease . , f! , . , . *u 

r . r , ^ A A . & 4 j , Importantly, the descnptions provided by the preprocessor 

of implementation, component reusability, and encapsula- 20 . *T . * 9 . r r . 4 ' £. f - , 

^ . r 4 . f . - J * * u mchide the size of each structure and the offset of each 

tion of information. This combination of advantages has . ... . t*. * -i li 

..... . . , r element within the structures. These values are available as 

resulted in the widespread use of IPC. . . j , , , ¥ 

r constants and may be used by programmers creating Java 

Over time, IPC techniques have been adapted to meet the programs 

demands of increasingly sophisticated programming envi- The Qt ^ mdudes a m,^. - Ille 

ronments. Many of these adaptations have attempted to * runtime Ubrary includes an inbuf Java class. The inbuf class 

make IPC technique, easier for programmers to use. In spite mdudes a of methods each designed to read a b^.^ 

of this evolution there are still arc where programmers Java such ^ an m , Qf character> from a byte TOy . 

find the use of IPC techniques to be difficult or error prone. ^ melhod accepts an argumeQ t telling the method the 

One of these cases arises when programmers attemptto use offcet ^in the b ^ e mat the read of me bui]t . in type 

IPC techniques to send and receive structures within pro- ^ to be performed 

cesses created using programming languages that do not n_ 4 T . . _ 

. , _.r f\_ » j , , , Programmers create Java programs to receive, mampulate 

provide support for structures. In more detail, high-level , **\ _ . • *u , 

f l a> ^ « i • ii ii and send C++ structures using the runtime Ubrary and the 

languages, such as C, C++ or Pascal, typically allow pro- , . , , , & ,„ v, „ 

& & * j* • / . ^ classes provided by the preprocessor. To receive a C or C++ 

grammers to group data into aggregates known as structures. . r c T 

f ^. . K structure, a programmer configures a Java program to call a 

In practice, programmers typically use structures to com- ^ M , _, ¥ r , Jr - . . ^ . 

_T * v i . 5 j . tl- ii i 4 « i . standard Java IPC melhod. The received structure is then 

partmentalize or group related data. This allows related data , . . _ , . .... 

f , . ~m . . » i* i stored as a byte array. To access a structure element within 

to be manipulated as a single entity. Thus, for example, a . . J A , J c A , T 

structure nright include datf describing a hardware device, ^ e ^J™* the Pf^B™? "'^T^ *?* 

j,, 6 ^. , to call the appropriate inbuf method. Thus, if an integer 

or data describing an employee record. Because structures . . . . j .u c »u T 

i . j j T • *. i r .An value is to be accessed, the programmer configures the Java 

contain related data, it is natural for cooperating processes to 40 . „ . ' - j f ♦ . « 

, ^ r to r program to call the inbuf method for reading integers. The 

exchange structures using IPC. au . c .u j • j i 

b programmer specifies the onset of the desired element 

Some high-level languages, namely Java, do not allow ^^bin the byte array using the description of the element 

data to be grouped into structures. As a result, programmers included in the appropriate class provided by the preproces- 

find it difficult to program Java processes to receive and ^ 

mampulate structures sent by other processes using IPC The 45 of ^ mven ti on will be set forth, in part, in 

lack of support for structures also makes it difficult to ^ ^ uon ^ follows aodf m part , wijj be understood 

programJavai processes to send structures to other processes b those skille d in the art from the description or may be 

using IPC. The unfortunate result is that it is difficult to leamed b tice of the nc Vantages of the 

construct systems where Java-based processes cooperate 5o ^ ^ realized and attained 5 means of the 

with processes implemented using more traditional elemeQts ^ particularly pointed out in the 

languages, such as C or C++. Since heterogeneous systems appended claims ^ equivalents, 
of this type are often useful, there exists a need for 

languages, like Java, to send, receive and mampulate struc- BRIEF DESCRIPTION OF THE DRAWINGS 

tures- 55 The accompanying drawings, that are incorporated in and 

constitute a part of this specification, illustrate several 

SUMMARY OF THE INVENTION embodiments of the invention and together with the 

The present invention includes a method and apparatus description, serve to explain the principles of the invention, 

that allows languages to send, receive and manipulate struc- FIG- 1 is a block diagram of a host computer system in 

tures defined by other languages. Structurally, the present accordance with a preferred embodiment of the present 

invention includes a preprocessor and a runtime library. The invention. 

preprocessor accepts, as input, source code written in a FIG. 2 is a block diagram showing the components 

high-level language, such as C or C++. The preprocessor included in a preferred embodiment of the present invention, 

produces, as output, a series of Java source code modules. FIG. 3 is a diagram of an exemplary C structure definition. 

Each Java source module output by the preprocessor 65 FIG. 4 is a diagram of a Java class created by the 

includes a Java class. Each class corresponds to one of the preprocessor of the present invention for the structure defi- 

structures defined in the preprocessor input. The preproces- nibon of FIG. 3. 
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FIG. 5 is a diagram of an exemplary nested C structure niques and Tools, Addison-Wesley (1986), Chap. 1-5, pp. 

definition. 1-342, the disclosure of which is incorporated into this 

FIG. 6 is a diagram of a Java class created by the document by reference. As a parser, preprocessor 200 rec- 
preprocessor of the present invention for the nested structure ognizes semantic constructs within input file 204. For most 

definition of FIG. 5. 5 semantic constructs, preprocessor 200 is configured to pro- 

FIG. 7 is a diagram of an exemplary C structure definition no output Thus, the default translation performed by 

that includes nested arrays of structures. preprocessor 200 is no output. The default translation is not 

0 . - T . . , . used, however, when preprocessor 200 recognizes semantic 

FIG. 8 is a diagram of a Java class created by the ^ ^ nd to stnlcture definitions 206. 

pn : prOC ^S,° f 7 the prCSent mVeDt1011 f0f Stmcmre dcfi - io Instead, preprocessor 200 produces an output file 208 con- 

nition ot HU 7. taining a Jaya dass 21Q for eadj stTUCt[JIC definition 206 

FIG. 9 is a flowchart showing the steps performed by a recognized in input file 204. 

Java program to receive and manipulate a C structure using The relation of structure definitions 206 to Java classes 

the Java classes and runtime library included in a preferred 2 10 is better understood by reference to structure definition 

embodiment of the present invention. 15 2 06' of FIG. 3 and corresponding Java class 210' of FIG. 4. 

FIG. 10 is a Java code fragment that corresponds to the As shown, structure definition 206' has a structure name 300 

method of FIG. 9. which, for purposes of illustration, is shown as the name 

"Coordinate3D.** Structure definition 206' also includes 

three integer elements 302a through 302c that are shown as 

20 X, Y and Z, respectively. In general, it is to be appreciated 

Reference will now be made in detail to preferred that structure definition 206* is intended to be exemplary of 

embodiments of the invention, examples of which are illus- the type of structure definitions 206 that may be included in 

trated in the accompanying drawings. Wherever possible, any C or C++ source code file, such as input file 204. 

the same reference numbers will be used throughout the FIG. 4 shows the Java class 210' output by preprocessor 

drawings to refer to the same or like parts. 25 200 for the particular structure definition 206'. Java class 

Environment 210* has a class name 400 that corresponds to structure name 

In FIG. 1, a host computer system 100 is shown as a 300 (i.e., both class name 400 and structure name 300 are the 

representative environment for the present invention. name "Coordinate3D"). Java class 210' includes four class 

Structurally, host computer system 100 includes a processor, members 402a through 402d. Each class member 402 is a 

or processors 102, and a memory 104. An input device 106 30 public final static integer. Each of the first three of class 

and an output device 108 are connected to processor 102 and members 402 corresponds to an element 302 included in 

memory 104. Input device 106 and output device 108 structure definition 206' of FIG. 3. Thus, class member 402a 

represent a wide range of varying I/O devices such as disk corresponds to structure element 302a, class member 402b 

drives, keyboards, modems, network adapters, printers and corresponds to structure element 3026 and class member 

displays. Host computer system 100 also includes a disk 35 402c corresponds to stmcmre element 302c. Preprocessor 

drive 110 of any suitable disk drive type (equivalently, disk 200 establishes this correspondence by naming each class 

drive 110 may be any non-volatile storage system such as member 402 to match the corresponding stmcmre element 

"flash** memory). A transaction manager 112, and one or 302. Thus, class member 402a and structure element 302a 

more threads 114 are shown to be resident in memory 104 are both named "X.** As described, preprocessor 200 names 

of host computer 100. 40 Java class 210 and class members 402 to match the corre- 

Overview sponding structure name 300 and structure elements 302. It 

Turning to FIG. 2 it may be seen that the present invention should be appreciated, however, that alternate naming 

includes a preprocessor 200 and a runtime library 202. schemes may be used without deviating from the spirit of the 

Preprocessor 200 operates on input file 204. Input file 204 present invention. In particular, there may be cases where 

contains C or C++ source code and includes a series of 45 mangled names (such as names including an initial 

structure definitions 206. For each structure definition 206 underscore) may be more appropriate. 

included in input file 204, preprocessor 200 produces a Preprocessor 200 initializes each of the first three of class 

respective output file 208. Each output file 208 contains Java members 402 to describe the corresponding structure ele- 

source code that defines a respective Java class 210. Java ment 302. In particular, each of these class members 402 is 

classes 210 act as descriptions of the structures defined by 50 initialized to be equal to the byte offset of the corresponding 

structure definitions 206. Programmers create Java structure element 302 within structure definition 206*. Thus, 

programs, such as Java program 212, that use the descrip- class member 4026 is initialized to the value of four since 

tions provided by Java classes 210. Together, the use of these stmcmre element 3026 is positioned four bytes from the start 

descriptions, along with calls to runtime library 202, allows of structure definition 206'. 

Java program 212 to receive and manipulate structures sent 55 Unlike class members 402a through 402c, class member 

by C or C++ programs, such as C program 214. Importantly, 402d does not correspond to a structure element 302. 

it will generally be the case that input file 204 will be one of Instead, preprocessor 200 initializes class member 402d to 

the files used to construct C program 214. In this way, C be equal to the total size, in bytes, of the structure defined by 

program 214 and Java program 212 automatically use the structure definition 206'. In the case of structure definition 

same definitions for equivalent structures. 60 206' of FIG. 3 the defined stmcmre includes three four-byte 

Preprocessor integers for a total of twelve bytes. Thus, for this example, 

Preprocessor 200 is preferably implemented as a parser class member 402a* is initialized by preprocessor 200 to have 

that accepts the C and C++ languages. In general, parsers of the value twelve. 

this type may be constructed using a range of generally FIGS. 3 and 4 show the correspondence between structure 

available parser generation tools, such as YACC or Bison. 65 definition 206' and Java class 210^. It may be appreciated, 

The design and construction of parsers is described in detail however, that structure definition 206 is relatively simple 

in Aho, Sethi and Ullman, Compilers: Principles, Tech- and includes no nested structures. The use of preprocessor 
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200 to create Java classes 210 for more generalized structure 
definitions is better understood by reference to structure 
definition 206" of FIG. 5 and corresponding Java class 210" 
of FIG. 6. As shown in FIG. 5, structure definition 206" 
includes two nested structures 500a and 5006. Each of these 5 
nested structures 500 is an instance of the Coordinate3D 
structure of structure definition 206* of FIG. 3. As a result, 
structure definition 206" includes a total of six elements. 
These structure elements are: Start.X, Start .Y, Start. Z, 
Stop.X, Stop.Y and Stop.Z. io 

FIG. 6 shows the Java class 210" constructed by prepro- 
cessor 200 for structure definition 206". Structure definition 
206" includes seven class members 600a through 600g\ 
Each class member 600 is a public final static integer. Each 
class member 600 corresponds to one of the structure l5 
elements included in structure definition 206". Preprocessor 
200 establishes this correspondence by naming each class 
member 600 to match the corresponding structure element. 
Thus, class member 600a is named "Start$X, class member 
6006 is named Start $Y and so on. 

Preprocessor 200 initializes class members 600 in the 20 
same fashion as described for structure definition 206* and 
Java class 210'. Thus, preprocessor 200 initializes each of 
the first six class members 600 to be equal to the byte offset 
of the corresponding structure element within structure 
definition 206". In the case of class member 600a, this value 25 
is zero. For class member 6006, this value is four. The value 
increases by four for each of the first six class members 600. 

Another example of the use of preprocessor 200 to create 
Java classes 210 for structure definitions is better understood 
by reference to structure definition 206'" of FIG. 7 and 30 
corresponding Java class 210 1 " of FIG. 8. As shown in FIG. 
7, structure definition 206 ! " includes two nested arrays of 
structures 700a and 7006. Array of structures 700a includes 
ten instances of the Coordinate3D structure (i.e., the struc- 
ture definition 206' of FIG. 3). Array of structures 7026 is 35 
similar, except that five instances of the Coordinate3D 
structure are included. Overall, structure definition 206'" 
includes fifteen instances of the Coordinate3D structure for 
a total of forty-five elements. These structure elements are: 
Start[0].X, Start[0].Y f Start[0].Z . . . Start[9].X, Start[9].Y, 
Start[9].Z and Stop[0].X, Stop[0].Y and Stop[0].Z ... 40 
Stop[4].X, Stop[4].Y and Stop[4].Z. 

FIG. 8 shows the Java class 21V" constructed by prepro- 
cessor 200 for structure definition 206'". Structure definition 
206'" includes seven class members 800a through 80Qg. The 
first six class members 800 are public final arrays of static 45 
integers. Each of these class members 800 corresponds to 
one of the structure elements included in array of structures 
702a or array of structures 7026. For example, class member 
800a corresponds to the element X included in array of 
structures 700a. Similarly, class members 800e corresponds so 
to the element Y included in array of structures 7006. 
Preprocessor 200 establishes this correspondence by declar- 
ing each class member 800 to match the corresponding 
structure element Thus, class member 800a is named 
"Start$X, class member 8006 is named StartSY, and so on. 55 

Preprocessor 200 initializes each class member 800 to be 
equal to the byte offset of the corresponding structure 
element within structure definition 206'". This is accom- 
plished by emitting a series of offsets for each class member 
800. For example, the offsets 0, 12, 24, 36, 48, 60, 72, 84, 
96 and 108 are emitted for class member 800b. The ofisets 60 
4, 16, 28, 40, 52, 64, 76, 88, 100 and 112 are emitted for 
class member 8006. 

Preprocessor 200 constructs a Java class 210 of the type 
shown in FIGS. 4, 6 and 8 for each structure definition 206 
included in input file 204. Together, the Java classes 210 65 
output by the preprocessor 200 form a complete description 
of the structure definitions 206 included in input file 204. 
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Runtime Library 

Runtime library 202 is preferably implemented to include 
a Java class inbuf. The inbuf class is declared as follows: 

one public class inbuf 

{ 

public inbuf (byte[ ] byte_array); 

public String readString (int oflset, int strlen); 

public byte readByte (int oflset); 

public char read Char (int oflset); 

public short readShort (int offset); 

public int readlnt (int oflset); 

public long readLong (int oflset); 

public byte[ ] readData (int offset); 

} 

As shown, the inbuf class includes an inbuf constructor 
that takes, as an argument, a byte array. The remaining 
methods included in the inbuf class read and return intrinsic 
Java types, such as Strings, bytes, chars and shorts. Each 
method for reading an intrinsic type takes an integer offset 
argument. Each method reads the appropriate intrinsic type 
from the byte array passed to the inbuf constructor at the 
oflset passed to the method. Thus, the inbuf class provides 
a generalized set of methods for reading intrinsic types from 
byte arrays and allows the offset for reading within the byte 
array to be specified. 

Internally, the inbuf method is preferably implemented 
using the standard Java.io package. The Java.io package 
includes a number of classes including a ByteArraylnput- 
Stream class and a DatalnputStream class. To use the Java.io 
package, the inbuf constructor creates a ByteArraylnput- 
Stream using the byte array passed to the inbuf constructor. 
The inbuf constructor then creates a DatalnputStream using 
the created ByteArraylnputStream. The DatalnputStream 
provides the methods that are used by the inbuf class to read 
and return intrinsic types from the byte array passed to the 
inbuf constructor. 

Together, Java classes 210 emitted by preprocessor 200 
and runtime library 202 provide a generalized method for 
manipulating C and C++ structures within Java programs. 
An exemplary use of Java classes 210 and runtime library 
202 is shown as method 900 of FIG. 9. Method 900 begins 
with step 902 where Java program 212 receives a C structure 
from C program 214. In general, it should be appreciated 
that step 902 may be performed using a wide range of IPC 
techniques and will generally require a combination of IPC 
routines called by C program 214 and Java program 212. In 
this way, step 902 corresponds to the use of these techniques 
to transfer the data included in a structure from C program 
214 to Java program 212. At the completion of step 902, the 
received structure is stored in a Java byte array. 

In step 904, Java program 212 creates an instance of the 
inbuf class for the newly received structure. Creation of the 
inbuf class is performed by calling the inbuf constructor, 
passing the byte array where the received structure is stored, 
as an argument. 

In step 906, Java program 214 reads an element of the 
received structure. To perform this read, Java program 214 
calls a method of the inbuf class instance created in step 906. 
To specify the offset within the byte array where the read 
will be performed, Java program 214 passes the class 
member 402 that corresponds to the desired structure ele- 
ment 302. 

In FIG. 10, a fragment of Java code illustrating the use of 
method 900 is shown and is generally designated 1000. At 
line 1002, Java fragment 1000 allocates a byte array using 
the Java new constructor. Since the allocated byte array is 
intended to receive a structure of the type defined by 
structure definition 206' of FIG. 3, the value 
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Coordinate3D.structlen (i.e., a value of 12) is passed to the 
new constructor. At line 1004, the Java I/O method read is 
called to receive the desired structure into the allocated byte 
array. Once again, the value Cbordinate3D.structlen is used, 
this time to inform the read method to read 12 bytes into the 
allocated byte array. Line 1004 corresponds, in a general 
sense, to step 902 of method 900. 

At line 1006 of fragment 1000, a new inbuf is created for 
the allocated byte array. This line corresponds to step 904 of 
method 900. In the following three lines (i.e., lines 1008, 
1010 and 1012), the inbuf readlnt method is called to read 
the X, Y and Z structure elements 302 from the allocated 
byte array. In each case, the appropriate class member 402 
is passed to the readlnt method. Thus, to read the X structure 
element 302a, the class member Coordinate3D.X is passed 
to readlnt. Lines 1008, 1010 and 1012 correspond to step 
906 of method 900. 

The present invention is capable of numerous embodi- 
ments. For example, it is entirely possible to create prepro- 
cessor 200 as a parser for languages other than C and C++. 
This allows Java program 212 to use structures defined using 
languages other than C and C++. Preprocessor 200 may also 
be configured to emit classes designed for use in languages 
other than Java. This allows the present invention to be used 
to pass structures to programs that are implemented using 
languages like Java that do not support structures. It is also 
possible for preprocessor 200 to encode additional informa- 
tion within class members 402. For example, type informa- 
tion might be encoded in class members 402 and then 
checked at runtime by Java program 212. 

Other embodiments will be apparent to those skilled in the 
art from consideration of the specification and practice of the 
invention disclosed herein. It is intended that the specifica- 
tion and examples be considered as exemplary only, with a 
true scope of the invention being indicated by the following 
claims and equivalents. 

What is claimed is: 

1. A method for using a structure defined by using a first 
programming language in a program defined by using a 
second programming language, the method including the 
steps, performed by a computer system, of: 

receiving a semantic construct that corresponds to a 
structure definition in the first programming language, 
the structure definition having a number of elements; 

defining a class corresponding to the structure definition 
using the second programming language; and 

defining one or more class members in the class, each 
class member corresponding to a respective element 
included in the structure definition, each class member 
initialized to be a value equal to the byte offset of the 
corresponding element in the structure definition. 

2. The method as recited in claim 1 further comprising the 
step of defining an additional class member which does not 
correspond with an element in the structure definition but 
which is initialized to be a value equal to the size of the 
overall structure definition. 

3. The method as recited in claim 1 wherein the structure 
definition has a structure name and wherein the class is 
defined to have a class name that is identical to the structure 
name. 

4. The method as recited in claim 1 wherein each element 
in the structure definition has an element name and wherein 
each class member is defined to have a member name that 
is identical to the corresponding element name. 

5. A method as recited in claim 1 wherein the class is 
defined as a Java class. 

6. A method as recited in claim 1 wherein the structure is 
defined as a C or C++ structure. 

7. A preprocessor for receiving programs and structures 
defined by using a first programming language and produc- 
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ing classes defined using a second programming language, 
the preprocessor performing the steps of: 

receiving semantic constructs and recognizing which 
semantic constructs correspond with structure defini- 
tions defined in the first programming language; 

producing class definitions in the second programming 
language, each respective class definition correspond- 
ing to a recognized structure definition; 

defining class members for each class definitions, wherein 
each respective class member corresponds with an 
element included in the structure definition correspond- 
ing to the class definition, each class member being 
initialized to be a value equal to the offset of the 
corresponding element described by that class member 
within the structure definition corresponding to that 
class definition. 

8. A preprocessor as recited in claim 7, wherein each class 
member included in a class definition is named after the 
element described by that class member. 

9. The preprocessor as recited in claim 7, wherein each 
class definition is named after the structure definition cor- 
responding to that class definition. 

10. The preprocessor as recited in claim 7, wherein each 
class definition includes an additional class member, 
whereby the additional class member is initialized to be a 
value equal to the overall size of the structure definition 
which corresponds to that class definition. 

11. The preprocessor as recited in claim 7, wherein the 
first programming language is C or C++. 

12. The preprocessor as recited in claim 7, wherein the 
second programming language is Java. 

13. A computer program product for receiving programs 
and structures defined by using a first programming lan- 
guage and producing classes defined using a second pro- 
gramming language, the computer program product com- 
prising: 

a computer-usable medium having computer-readable 
code embodied therein for performing the steps of: 
recognizing structures defined in the first programming 
language; 

producing class definitions, each respective class defi- 
nition corresponding to a recognized structure; and 

defining class members for each class definition, each 
respective class member describing an element 
included in the structure corresponding to the class 
definition, with each class member included in any 
one class definition initialized to be a value equal to 
the byte offset of the element described by that class 
member within the structure corresponding to that 
class definition. 

14. A computer program product as recited in claim 13, 
wherein each class member included in a class definition is 
named after the element described by that class member. 

15. A computer program product as recited in claim 13, 
wherein each class definition is named after the structure 
corresponding to that class definition. 

16. The computer program product as recited in claim 13 
wherein each class definition includes an additional class 
member, the additional class member initialized to be a 
value equal to the size of the structure corresponding to that 
class definition. 

17. The computer program product as recited in claim 13 
wherein the first programming language is C or C++. 

18. The computer program product as recited in claim 17 
wherein the second programming language is Java. 

19. The computer program product as recited in claim 15 
wherein the class definitions and class member definitions 
are produced using a second programming language. 
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SOFTWARE UPGRADES BY CONVERSION 2. The text delta Gist of changes in the program text) may 

AUTOMATION be very large, even where (semantically speaking) what is 

BACKGROUND OF THE INVENTION happening is simply a specific change which could be stated, 

. . ,. . ....... , in English, in a sentence or two. (For example: "Change all 

This invention relates to a conversion declaration for use , rea(J ££ rences to m*^^* to cmrent_envlta 

m upgrading source code of a program and to a program- references to data base" 

mine compiler for implementing conversion declarations. . , — r ^ ° . " ^ , , — , — 

xT » w u ii - i « • ... index from data_base_index=Newvalue to log_ update 

Most high level programming languages used in writing ( . . . . NewVa hie »\ 

large software programs (e.g., JAVA, C, C++, COBOL, ^ta_base^naex^ew Value. ) 

FORTOAN-IV, FORTRAN-90, ADA, PL/1, MODULA-2, 7^? makes trackmg the system changes a huge job: it hides 

MODULA-3, EIFFEL, ML, HASKELL, SATHER) have a 10 mdmduaI1 y significant changes by burying them in masses 

type system and are statically compiled in compilers which °^ stereotv P ed changes- 

check types and usages (i.e. semantic usages) at compile A final problem area for text-based pattern-matching and 

time. A "type system" means that each variable in the substitution systems is that they are not scoped in the same 

program has a type associated with it. Example types are wav ^ normal program entities. Consider, for example, the 

integers, floating point numbers, and characters. It is often 15 following C code fragment: 
necessary to upgrade such a software program. To facilitate 
this process, text-based pattern matching and substitution 
systems are known. However, such systems have a number 
of drawbacks which may be highlighted by considering the 

following C code fragment: 20 



01 { int my_var = 7; 
02 

03 struct MS { 



01 


extern int K; 


02 


#define incrfX) (X +- K) 


03 


void next step (double J,K) { 


04 


{ 


05 


inl count - current_count; 


06 


incr(count); 



25 

04 to£my_var, O^e " • • • " represents omitted material.) 

05 char code; If a programmer wrote code along the above lines, then 

06 } my_jitruct; the effect of the call to the incr macro on line 06 would 

08 m struct almost certainly not be what the programmer intended. Its 

09 ^""m^var = 12.0 + my^tiuctmy^ 30 effect, as written, would be to increase the value of the local 

10 count variable by the value of the double parameter, K. 

11 { char my_var = *M'; However, from the declaration context on lines 01-02, it 

12 char other_var - my_var + tiunc(my_stnict.my_var); appears that the intent would be that count should be 
14 r* r m S y--^yl-7^o U , - noo - incremented by the value of the extern int K. 

zero 35 The problem is that the scope of macros is entirely 
— ^— different from that of ordinary declared program entities 
, . . . (variables, constants, routines, types, etc.). Here, the han- 
A text-based pattern matching and subsUtution system dlingof mcr is done by the Cpre-proc^r(cr^) which uses 
cannot distinguish among the three different variables a completely different processing strategy from the C corn- 
named my_var,declared on lines 01, 04, and 11, without piler proper? ^ takes no cognizance of C scoping rules, 
heroic efforts. That is because the semantics of an identifier This invention seeks to overcome drawbacks of prior 
can be highly diverse within a single program in almost any software upgrading systems, 
high-level programming language. * " 

A text-based system also has considerable difficulty dis- SUMMARY OF INVENTION 
anguishing between the two different kinds of accesses to 45 According to the present invention, there is provided a 
my_struct.my_var on line 09: the first occurrence is a write conversion declaration for use in upgrading source code of 
access, and the second is a read access. a program which has a type system and is statically compiled 
A text-based system cannot tell that the expressions in a compiler which checks types and usages at compile 
my_strucLmy_var on line 09 and my_var_ptr->my_var time, comprising: a list of substitutable parts, with each 
on line 14 are denotationally identical (except possibly for 50 substitutable part having a list of properties; a set of one or 
the structure instance affected), because they do not 'look* more semantic patterns to be matched using said substitut- 
alike. able parts; and a result pattern showing what will be sub- 
Similarly, a text-based system cannot easily distinguish stituted for each matching portion of said source code, 
among expressions by type: for example, it cannot readily A compiler utilizing such a conversion declaration is also 
recognize that on line 12, my__var is a char-valued expres- 55 provided. 

sion (that is, it is a character type expression), whereas trunc According to another aspect of the present invention, 

(my_struct.my_var) is an int-valued expression (that is, it there ^ provided a method for upgrading a source code of a 

is an integer valued expression). program of a type which has a type system and is statically 

Another problem area for text-based pattern matching and compiled in a compiler which checks types and usages at 

substitution is that, due to the lack of type- and usage- 60 compile time, comprising the steps of: comparing portions 

checking associated with text-based substitutions, the of said source code with semantic patterns in a set of one or 

changes made in the program text must be checked by more semantic patterns and a list of substitutable parts, with 

responsible, expert programmers. This creates two difficul- each substitutable part having a list of properties; on finding 

Ues: a matching source code portion, determining whether said 

1. Checking is significant work for the responsible expert 65 matching source code portion comprises a pre -selected type, 

programmers, especially where the program is large and the procedure or module and, if so, converting said matching 

changes are not isolated to a small portion of the program. source code portion to a result pattern. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

In the figures which illustrate preferred embodiments of 
the invention, 

FIG. 1 is a representation of a semantic tree, 5 
FIG. 2 is a representation of a semantic pattern, 
FIG. 3 is a Polish form representation of a source code 
fragment, 

FIGS. 4a and 4b are Polish form representations of source 
code fragments, and 10 

FIG. 5 is a schematic representation of a computer system 
embodying the subject invention. 

DETAILED DESCRIPTION OF THE 

PREFERRED EMBODIMENTS 15 

The subject invention employs a semantic-based conver- 
sion of a software program in order to effect a modification 
to the program. This conversion is accomplished by the use 
of conversion declarations (together with any necessary ^ 
declarations which define variables used in the conversion 
declarations) which are inserted at appropriate places into 
the source code and by appropriate modification to the 
compiler in order that it may handle the conversion decla- 
rations. At compile time, these conversion declarations are ^ 
executed, as many times as necessary, to implement the 
desired modifications throughout the program. 

To facilitate understanding of conversion declarations, 
two known semantic devices are first explained: semantic 
trees and semantic patterns. 30 
Semantic Trees 
Consider the C expression: 

4«>#-i]*k-i>7O0 35 

where the following C rules, denotes assignment of its 
right operand to its left operand (and not comparison or 
equality). 

This expression is represented as the semantic tree of FIG. 
1. It will be noted that the form of the tree follows from the 40 
precedence and associativity of the operators and the paren- 
thesizing of the operands. 

The leaf nodes (x, i, x, i, 1, g, 1, f, y) represent operands. 
The internal nodes represent language-defined operations 
which, in this case are meaning "assign"; "[]" meaning 45 
"index"; meaning "multiply"; "-" meaning "subtract; 
and "0" meaning "function call". 

Note that textual details such as parentheses (where they 
do not denote the function call operation) are omitted. 
Grouping of operands is implied by the semantic tree with so 
no need to include the parentheses as one might for a 
text-oriented parse tree. Ordering of the operand edges in the 
tree from left to right is significant, because x-y and y-x are 
quite different semantically. Even sub-trees composed 
entirely of mathematically associative and commutative 55 
operations, such as addition, cannot actually be restructured 
without a change of semantics when hardware floating point 
operations are used for implementation. Properties, such as 
loss of significance, can depend greatly on expression tree 
structure, so what the programmer coded should be what 60 
happens. 

FIG. 1 illustrates all but one essential property of a 
semantic tree: All mode identifications denoting specific 
entities or operations must be exact. For example, the type 
of the operands is relevant to the operation performed for all 65 
interior nodes, and the exact denotation of variables and 
functions also. Thus, the node identification for a node 
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labelled "u" would distinguish the type of u and distinguish 
that particular u from any other distinctly declared u in the 
program. 

For example, if u were a long int (i.e., a long integer) 
declared in the second block nested within the third block 
nested within function h, then the identification for a node 
labelled u might actually be something like: 



( name: 


u 


type: 


long int 


scope: 


local 


function: 


b 


blockjoc: 


(3,2) 


) 





whereas if u were a float (i.e., a floating point number) 
declared to be global in scope as an extern, then its identi- 
fication might actually be something like: 



( name: u 

type: float 

scope: extern 

function: — 
blockjoc: 

) 



The use of "~" does not mean "unspecified". It means 
"absent" or "not applicable here". That is, use of "~" is 
precise. It indicates something which is definitely not 
present or applicable. 

Type information for such specifications must be com- 
plete. For example, a bit-field three bits wide might have a 
type specified by 

type: unsigned int :3 
and an array parameter in a function might have a type 
specified by 

type: float [50] [] 
That is, bit-field width and known array dimensions) is 
relevant "type" information. 

Individual occurrences of an identified identity such as the 
two different kinds of u above also need access mode 
information. Which access modes exist will depend on the 
programming language. For example, a variable in C can be 
accessed in the following ways: 

1. Variable address (var_addr): An example is the C 
expression, &x which takes the address of an addressable 
variable x. This includes the case of a structure or union 
where a member is addressed. 

2 . Constant address (const_addr): Same as 1., except that 
the variable addressed has the const attribute. This includes 
the case of a constant structure or union where a member is 
addressed. 

3. Assign to addressable variable (var_assign): The mode 
of an addressable non-const variable which is the left 
operand of - in an assignment or the initialization of a 
declaration. 

4. Read and assign addressable variable (var_update): 
The mode of an addressable, non-const variable which is the 
operand of prefix or suffix ++ or — or the left operand of +«, 

*=, /=, %=, &=, =, |=, «=, or »=, or the mode of a 
struct or union variable when one of its members is modified 
in part, or read and assigned, or simply overwritten. The 
reason that a union member assignment is not treated as 
having var_assign access mode is because there may be 
'slack bits' not occupied by the assigned member, members 
of a union need not all have the same size in memory. 
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5. Initialize addressable constant (const_assign): The 
access mode of a newly declared non-bit-field const variable 
which is being initialized by = in a declaration. 

6. Read addressable variable (var read): the access mode 

of any addressable non-const variable in all contexts except 
those mentioned in 1., 3., and 4., including the access mode 
of a structure or union when a member is read-accessed. 

7. Read addressable constant (const_read): the access 
mode of any addressable const variable in all contexts 
except those mentioned in 2. and 5., including the access 
mode of a constant structure or union when a member is 
read-accessed. 

8. Assign to bit-field (bit_assign): the access mode of any 
bit-field variable which is the left operand of = in an 
assignment. 

9. Read and assign bit-field variable (bit_update): The 
mode of a bit-field variable which is the operand of prefix or 
suffix ++ or — or the left operand of one of +», *=, /=, 
%=, &=, =, |=, ««, or »=. 

10. Read bit-field (bit__read): the access mode of any 
bit-field variable in all contexts except those mentioned in 8. 
and 9. 

11. Pure value (pure_val): the access mode of a pure 
value; i.e., one not immediately tied to any memory location, 
such as the value of an expression such as "(x+1)" or the 
value returned from a function call. 

12. Unvalued (no_val): the access mode of a statement, 
or of an expression preceding a "," operator — whether or not 
it provides a value, it certainly provides no value which is 
used. 

Note that fine distinctions are made among modes in the 
C language. The access mode has a profound effect on what 
semantic substitutions are legitimate (for example, for mode 
9., a substitution which used the & (pointer to) operator, 
which needs an addressable operand, would not be 
appropriate). 

Thus, a full identification of the foregoing node labelled 
"u" would be as follows: 



( name: 


D 


type: 


float 


scope: 


extern 


function: 




blockjoc: 




acccss_jnode: 


var_read 


) 





where the access mode specifies that u is a read-only 
variable. 

Semantic Patterns 

A semantic pattern is a semantic tree in which the speci- 
fication of one or more nodes may have been made less 
precise in order to allow various semantic trees to match it. 
In fact, semantic trees comprise that subset of semantic 
patterns in which all nodes are precisely identified. 

An example semantic pattern is illustrated in FIG. 2. 
Referencing FIG. 2, capitals are used for the names of 
pattern wild-cards to distinguish them from ordinary 
declared variable and constant names. 

If, referencing FIG. 2, x is an array of type float and U and 
V are specified as follows: 



6 



5 



( name: 


U 


type: 


long int 


scope: 


? 


function: 


? 


blocXJoc: 


? 


access_mode: 


var_rcad | var_assign 


) 





10 

(where the a var_read|var_assign" access mode specifica- 
tion indicates that a match is possible for either of var__read 
or var_assign access mode, and "?" is used to indicate 
"don't care", i.e., anything matches this part of the pattern 
element specification) 



20 



( name: 


V 


type: 


float 


scope: 


? 


function: 


? 


blockjoc: 


? 


access__mode: 


var_read 


) 





25 then the semantic pattern of FIG. 2 matches the semantic 
tree of FIG. 1. 

Note that a pattern variable differs from an ordinary 
declared variable or constant in being incompletely 
specified, either through the use of alternatives (as in "var__ 

30 readjvar_assign" above) or through the use of 'don't cares' 
specified above by "?". 
Conversion Declarations 

The essential information which is provided by a conver- 
sion declaration is as follows: 

35 1. A list of substitu table parts and their properties (with 
information on what parts of their descriptions are fixed, 
which have multiple options, and which are "don't cares'* as 
in the description of U and V above). 

2. A set of semantic patterns to be matched using the 
40 substitutable parts provided in 1., including precise specifi- 
cations of the fixed parts of the semantic patterns. In this 
regard, the context of the conversion declaration can typi- 
cally be used to set some aspects of the fixed parts of the 
semantic patterns. For example, where a fixed part is rep- 

45 resented by a name, say, "xyz", that name will have all of the 
properties which are tied to it at the point in the program at 
which the conversion declaration occurs. By way of 
explanation, any name has a "scope" in the program, which 
is the parts of the program in which the name is visible. For 

50 example, the name "xyz" could be declared in two blocks, 
one nested within the other. In each block, the name could 
have entirely different properties. If a conversion declaration 
were added to the outer block and used "xyz" as a name 
representing the source pattern, "xyz" would have the prop- 

55 ernes assigned to it in the outer block. 

3. A result pattern which shows what will be substituted 
for the matching source program entity. A result pattern may 
also have fixed parts, if so these follow the same scoping 
rules as those followed in respect of source patterns. 

60 4. What the conversion is tied to, i.e., the conversion can 
be tied to a type, a procedure (e.g. sub-routine), or a module. 
If the conversion is tied to a type, an otherwise matching 
source fragment will only trigger the conversion if the 
source fragment type matches the type specified in the 

65 conversion declaration. On the other hand, if the conversion 
is tied to a variable or procedure, then an otherwise matching 
source fragment will only trigger the conversion if the 
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source fragment matches the variable or procedure specified results are precise, the substitutions turn the result ^pattern 

in the conversion declaration. The conversion may also be in to the result semantic tree. The compiler generates code 

tied to some entity other than a type, such as use in a as if the result semantic tree, rather than the matching 

particular module. In the case of C, the issue of modules semantic tree, had been written in the first place, 

does not arise. After the C p re-processor, cpp, has been run, 5 entire__mode 

the compiler is dealing with just one single source program This specifies the permitted access mode(s) of the entire 

contained in one text file. matching source fragment. A match will not occur unless the 

A conversion declaration is scoped in the same fashion as matching program entity has one of the specified access 

routines and types, with symbols in them fixing their mean- mo des 

ings at the point where the declaration occurs. With a lQ mode- 

conversion declaration^ then, the meaning of an exprasion ■ ^ 

such as "extern int K» is fixed at its declaraoon and any OTnve ^ ondeclarationiscmbedd ^« sel ^ mode .. isusedto 

later, more local, definition of K has no effect on the t j_ * j r • « 

, . ' . _ « * restrict what access modes for instances of "self are con- 
conversion declaration. Thus, conversion declarations are . , , , . 

, sidered matches. 

exic y scope . 15 The source oattern,; source_pattern 2 ; . . . ; source_ 

This essential mformation may be specified m a conver- * «u - , , 4 . 

. j . . . . .-a. f j * , c pattern • portion of the conversion declaration may some- 

sion declaration m many different ways. In a preferred form, f. 4t * - - w 1 * . « 

, , . J . . . ./ r . ' times use patterns containing multiple statements. To handle 

a conversion dec aration has the following syntax: convert ^ Cof Q m J ^ ments ^ ^ 

entire_mode [self_mode; parm,, parm,, . . . , parmj ^ ^in^he source_patterns, since T 

to 1 ^ a^ i;SOUrCe SOUrCC - P em " ; 20 ™ "ever begin a statement in C or C + ^The same device 

_ r~^f m ' . . , j r 11 can be used where such groupings are required in the 

The parts above are to be understood as follows: , „ 4 , , • u , , 

v result_pattern. Other techniques can be used, depending on 

parmj, parm 2 , . . . , pann„. the programming language. 

The parameters specify (i.e., list the properties of) the i£ r j * r A 1 *• . „ 

^ • \L »- ~ *jw *u The preferred syntax for a conversion declaration may be 

substitutable parts in the semantic patterns generated by the „„ . 44 , 4 . . r*u <• n . . 4| _ 

« 1 *; 1 • j 1 4 • 25 better understood by way of the followmg examples in the 

conversion declaration. In some conversion declarations, ^ language 

there will be no parameters. Consider first a simple example involving a system which 

in tne preterred embodiment, me syntax tor any one handks 

transactions. To keep track of the number of trans- 

parame er appearing me actions processed, the system increments a transactions 

parmj, parm 2 , . . . , parm m p is. ^ co™^^ count, maintained as a long integer: 

access_mode__alternatives type name ++ trans_count-^)r-trans_count ++ 

where access_mode_altemauves either have the form of ^ m ^ ^ modified to proccss transactions in 

a list of one or more access modes separated by f: parallel The former code for updating trans__count is no 

access_modeJaccess_mode 2 | . . . | access_mode* longer safe, because the increment is not guaranteed to be 

or are specified as 35 atomic. Therefore all such updates need to be replaced with 

any_mode one 0 f the following calls, which call routines implemented 

(meaning any access mode is an acceptable match, in to accomplish the equivalent increment actions atomically: 

other words, the access_mode is a "don't care" attribute), i ong pre__incr_trans_count 0 /*if the value is used and was 

and each specifically indicated access_mode is one of: p re-incremented.*/ 

40 long post_incr_trans_count 0 /*if the value is used and 
was post-incremented.*/ 

var _ read const__xead bit_read incT_trans_count Q /*if the value is not used and was 

var_asstgn const_assign bit_assign pre -incremented or post-incremented. */ 

var_update const__addr bit_update All of this can be accomplished system-wide by the 

var_addr 45 following three conversion declarations (included in an 

appropriate C header file): 
convert pure_val [] ++trans__count; to pre_incr_trans_ 

The name is the name of the substitutable part count(); 

sourcejattenij; source_pattem 2 ; . . . ; source_pattern„; convert pure_val [] trans_count++; to post_incr_ 

These are source language fragments, such as expressions or 50 trans_count(); 

statements, which together with the information provided by convert no_val [] ++trans__count; trans_count++; to 

the parameters, and the information provided by the prop- mcr_trans_count(); 

erties of names in the context in which the conversion The pure_val and no__val modes above constitute the 

declaration appears, are sufficient to generate the semantic entire_mode specification, indicating that the expression to 

patterns to be matched when the conversion declaration is 55 be substituted (++trans_count or trans_count++) in its 

applied. entirety, has the pure_val access mode, since the value of 

result_pattern either ++trans_count or trans_count++ is the value of 

The result__paltem determines the result of applying the (trans__count+l), which has the pure_val access mode. (The 

conversion declaration. Suppose a match occurs between a access mode of trans_count itself in the above is, of course, 

particular source fragment source_pattern, (viewed as a 60 var_update.) 

semantic tree: the matching semantic tree) and the semantic Note that the above conversion declarations would have 

pattern produced for source_pattern I . Then the result is to be declared where the system-wide trans__count was 

found by converting the semantic pattern produced by the already defined. The implementation would use the declared 

result pattern into a semantic tree by substituting for the meaning of trans_count in its semantic patterns for the 

substitutable parts in the result_pattern those subtrees of the 65 above conversion declarations, so that if any programmer 

matching semantic tree which match them when source_ declared some other entity named trans_count, whether of 

pattern, is matched to the matching semantic tree. Since the the same or a different type, it would not match the semantic 
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patterns based on the above declared meaning of the trans_ non_owner_visit_count and the conversion declaration 

count name, and would not in any way be affected by the within the trans_context struct's declaration. The only other 

above three conversion declarations. things left to do to complete the counting job is to add code 

Now consider a more complicated example involving a to place the non_owner_visit_count in global memory 

(serial) transaction procession system. The bodies of soft- 5 with an initial value of zero, and to output the contents of the 

ware handling different kinds of transactions are distinct, non_owner_visit_count at an appropriate point, and then 

and are associated with unsigned short identifier values, so mi] th e sy stem. All the rest of the work is done by the two 

that body of software which is handling a transaction can be added declarations 

tracked during execution. Lc t > s ioo k at the details of what the above conversion 

Each transaction is associated with a struct called a ^ A , . „ «. . , - 

. . . - . , . , f , . ■ . , . 10 declaration actually says. First, the conversion declaration 
trans context which keeps track of data associated with that ri . „ , . _~ . , j ... . _^ _w,. 
transaction. Included in Vtrans_context is a trans_owner ^es 06-15) is placed within the trans^context struct (hues 
member, which indicates the body of software which origi- ^'[^ 7015 mdlc r ales thal ^ ™™™™ » triggered only 
nally was selected to handle the transaction and continues to m tbc presence of an instance of the type "struct trans_ 
have overall responsibility for handling it. Different trans_ context" (specifically, m the program context shown, by the 
contexts can be linked together during execution so that one 15 appearance of self in the source_pattern on line 10). 
transaction's handling can be modified depending on the no_val (line 06) is an entire_mode which indicates that 
data of other transactions which are in progress. we are interested only in cases where the entire affected code 
When one transaction-handling body of software 'visits' fragment does not return a value (i.e., appears as a 
a transaction by a link, rather than directly accessing its statement). The self__mode, var_update, (line 07) indicates 
owned transaction, it records that fact by setting the visited 20 that we are looking for cases where the instance of the type 
transaction's last_visitor member, so that, if something goes "struct trans_contexf is being updated. The next two lines 
wrong, dependencies on linked transactions can be tracked define properties of a substitu table part, visitor_act_id, for 
for debugging purposes. tne semantic patterns. Specifically, var_read|const_ 
Suppose a modification to this system is being considered read|pure_val indicate that visitor_act_id may be a read- 
which will convert it from serial to parallel form, where each 25 able variable, readable constant, or some other value- 
transaction-handling body of software runs as a sequential oriented expression, unsigned short indicates the visitor_ 
process, but the various transaction-handling bodies of soft- act_Jd is of type unsigned short. 

ware run in parallel with one another. However, before doing source __pattem (line 10) says that we are looking for 

so, an estimate is required of the mutual-exclusion overhead me occurrence of an assignment in which the last_visitor 

which will be incurred by visits to linked transactions. 30 member of an instance of the type "struct trarJS_contexT is 

Sometimes a linked transaction will turn out to be simply the assigned the value of our substitutablc part (i.e., last_visitor 

current owned transaction, and would therefore incur no k assigned an unsigned variable, constant or pure value), 

added overhead. Therefore, we need to count those visits in Th e appearance of self represents where in the source 

which the visited transaction is not the current transaction pattern our instance of the type "struct trans_context" must 

before any changes are made to make the system parallel. 35 appear. 

Suppose x is some trans_context, and we are visiting it by Th e result_pattern (lines 12-15) says that, when a match 
a link (a pointer in some other context's data). We indicate occurs on the above criteria, we replace the matched frag- 
that we are visiting it by executing ment (an assignment statement) by the statements within 

x.last_visitor-my_jd; square brackets, namely the same assignment statement 

where my_jd denotes whatever declared or literal constant 40 followed by an if-statement which checks to see whether the 

or variable holds the identifier for the transaction-handling va lue of the substitutable element, visitor_act-id, is the 

body of software in which this code is executed. same as the owner member in the matching instance of type 

A fragment of the data structures in this system is shown, "struct trans_context", and if not, increments the non_ 

as it appears after addition of conversion declarations to owner_visit_count variable. 

perform the needed counting of visits to unowned tr ansae- 45 For conversion declarations to operate properly in all 

tions: situations, two additional capabilities are required — 

avoiding recursion and handling deletions — which are dis- 
cussed here following. 
Literal Source Fragments 



oi cxicm unsigned long non_owncr_visit_count; /* added*/ 50 since conversion declarations work by substitution prior 
03 "'''^^'IhoT { trans.owner, to ob J ect code gyration, rather than by closed linkages, 



04 struct trans_data *input| •output; they cannot invoke one another recursively. (To do so would 

05 unsigned short lasL_visitor, be to incur an infinite expansion.) 

However, there are occasions where we want the result_ 

06 convert no_^^ /*added*/ 55 p attera Q f a conversion to be similar to a source_pattern. To 

08 varJread|const_readipure_val prevent recursion in such cases, we need to provide a literal 

09 unsigned short visitor_jict_id ] facility, which indicates that what the programmer wrote is 

10 self.last_visitor - visitor_act_id; ^ ^ taken as written, and not modified by any conversion 

12 10 [ seif.iast_visitor-visitor_3ct_id; declaration invocations. The syntax used for expressing this 

13 if (visitor_nct_id !- self.owner) 60 will of course, vary with the programming language in 

14 ++non__owner_visit_count; question. For C or C ++, the preferred embodiment is to 

15 , 1 allow source code forms such as any of: 

16 } /*end struct trans_context*/; 



literal selection_statement 

literal iteration_statement 
What has been added to the original system to perform the 65 literal compound__statement 
counting is shown above as the two declarations marked by literal (expression) 
the "/* ADDED *r comments: namely, the declaration of the literal [statement_list] 
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The meaning of a literal code fragment is its 'literal' 
meaning; i.e., its original meaning unmodified by any con- 
version declarations. The effect of making it literal is that 
neither the literal fragment, nor anything within it, can 
invoke a conversion declaration. In the preferred 
embodiment, the meaning of the statement, expression, or 
statement_list modified by literal is the same as it would be 
without the modifier literal, except for one thing: neither the 
entire literal-modified entity, nor anything within it, matches 
any source_pattern within a conversion declaration. 

literal cannot be used within a source_pattern of a 
conversion declaration (source_pattems are implicitly lit- 
eral to start with). It may, however, be used in a result 

pattern, or in ordinary program source text. 

As an example to motivate the use of a literal facility, 
consider the following problem: we want to find out how 
often entities of type struct data_handle are accessed in the 
execution of a system. This can be implemented as follows: 



/•ADDED'/ 
/* ADDED*/ 



/* ADDED*/ 



01 extern unsigned long data_handle_aocess_count; 

02 data_Jbandle *access_data_handle (data_Jianrtle *); 

03 struct data ^handle { 

04 convert any mode [any mode;] 

05 self, 

06 to 

07 litcral(*acccss_data_Jiandle(&scif)); 

08 }; 



09 data__handle *access_data__handlc (data_handle *dh) (J* ADDED*/ 

10 ++data_handlc_acccss_count; 

11 return literal(dh); 
12} 



10 



12 



patterns. Once all conversion declarations have done their 
work, all absent entities must have disappeared from the 
executable code. 

In the preferred embodiment in C or C ++, absent entities 
are declared by using the word absent (indicating that 
entities of this type do not exist at run-time) as a type 
qualifier (like const, indicating that the entity cannot be 
modified, inline, indicating that a function is to generate 
in-line code where possible, or volatile, indicating that the 
variable may change at any time due to the action of multiple 
accessing threads of control). 

For example, suppose we have a large system in which we 
have a date structure defined as: 



15 



20 



struct date { 
unsigned int 



}; 



dd:5, 

mm:4, 

yy:7; 



/* Day of month */ 
/* Month of year */ 
/* Year minus 1900 */ 



where we have, assuming a suitable C implementation, 
packed the date into 16 bits, at the cost of limiting ourselves 
to years between 1900 and 2027, inclusive. 

25 Suppose we discover that we must handle a wider range 
of dates: we now need years before 1900 and after 2027. 
However, the date structure has been used wholesale 
throughout our entire system. Conversion declarations 
together with an absent entity facility can address this 

30 problem, as follows. 

We redeclare our date structure as follows: 



In our example, the declarations marked "/* ADDED*/" 
have been added to the original system to support counting 35 
the accesses to data_handles during execution. We have 
added access to a counter in which to keep counts of 
accesses to data_handles (line 01). We also define a function 
to do the counting (line 02). 

Inside the declaration of the struct data_handle type, we 40 
place a conversion declaration (lines 04-07), such that when 
we express a data_handle, x, in our code, it will be compiled 
as (*access__data_handle (&x)). Hence every execution of 
an access in the original program will increment the counter 
in the corresponding converted program. 45 

Note the use of literal in the above. Without the use of 
literal, the result_pattem (line 07) would access itself at two 
points: the entire result_pattem, since it denotes a data_ 
handle, would invoke the self-same conversion declaration, 
and self, denoting a conversion declaration, would also 50 
invoke it. 
Absent Entities 

Sometimes what is to be accomplished with a conversion 
declaration involves deleting a named entity (usually, 
replacing it with another). Yet conversion declarations use 55 
semantic patterns, which means that its patterns use names 
with semantics already aUached. The named entity might be 
a global variable, a member in a structure, a routine, or any 
kind of entity with a name or type attached. 

To support this, absent entities are provided. An absent 60 
entity has the same type and properties as its corresponding 
'present' entity, except that it does not exist at run-time; i.e., 
it is a compile-time place-holder for type-checking and other 
semantic properties. How it is expressed will depend on the 
programming language in question. 65 

When an entity is absent, then (aside from its declaration), 
it can only appear in conversion declaration source_ 



01 


struct date { 


02 


unsigned int dd : 5, /* Day of month */ 


03 


mm : 4; /* Month of year */ 


04 


signed int yyyy :23; /* Year */ 


05 


absent 


06 


unsigned int yy : 7; /* Year - 1900 7 


07 


convert any__mode [var_update; 


08 


var_read|const_read|pure_val int E] 


09 


self.yy - E; 


10 


to 


11 


self, yyyy - E + 1900; 


12 


convert var_readjconst__read [var__jeadJconst__read;] 


13 


self.yy, 


14 


to 


15 


self.yyyy - 1900; 


16 


}; 



The absent member declared on lines 05-06 takes up no 
space in a date and does not exist at run-time. Due to the 
conversions on lines 07-11 and 12-15, all read and write 
references to the old yy year bit-field are replaced by 
equivalent accesses to the new yyyy year bit-field, which has 
sufficient capacity to refer dates from 4, 194, 304 B.C. to 4, 
194, 303 A.D. (assuming a suitable C implementation). 
Equivalent Source Text Capabilities 

So far, we have discussed basic uses of conversion 
declarations to implement wide-ranging changes in a large 
system using a few strategically placed conversion 
declarations, without further changes to source text. 

However, there are cases where it may be desired to have 
access to equivalent source code changes as well. Some 
obvious examples are: 

1. In a debugger, we may want to make the semantics of 
any invoked conversion declarations, in addition to what the 
programmer wrote, visible, so that the user can more easily 
understand what is happening in a debugging session. 
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2. Similarly, we may want to make visible the semantics names, used in their patterns, to be defined, then any 
of any conversion declaration invocations triggered by pro- program fragment which can 'see' a conversion declaration 
gram fragments wheo an annotated compilation listing of the which uses the member names must obviously have tra- 
code is produced. versed the source text which declares them, and all code 

3. We may want to employ a particular conversion dec- 5 which 'sees' such declarations has exactly the same level of 
laration as a temporary transitional step, planning to replace access to the declared entities. 

the source code in the long run so that the transitional In c++ and man y other languages, however, visibility 

conversion declaration is no longer needed. contro1 can be a Uve issue - Generally, the problem is that 

For all of the above reasons, a compiler with conversion CC ^ S F members or components are permitted to be used 

declaration capabilities may be deployed along with a source 10 ^ m cer ? m wthm me tex * for ** ^f 5 J"- 

expander facility. The source expander can then be used by K Pnvate members of a C++ class can only be 

.« * « #l * . ... f, . . . , / accessed by a member function or friend function or friend 

the debugger, the lister, and the library maintenance tools to cJass of ^ 

address needs 1-3 above Note that the compiler still has complete information on 

Hie source expander facility takes the source code and ^ privileged components. Therefore, all that is needed to 

generates new source text which has exactly the same is be able to f ac ii ita te the work of the source expander is to 

semantics as the original source text, but in which certain provide an easy way for the modified source text generated 

specific conversion declarations are no longer invoked. by the source expander to refer to elements with privileged 

Generally, the source text changes required tend to be local access in the 'wrong' scopes. 

to the invoking source fragments, but sometimes wider In C++, the component access operators are "::", ".", and 

changes are required to preserve semantics. 20 "->", used, respectively, to access class members, members 

Where conversion declarations are to be used as a Iran- in class instances, and members in target class instances 

sitional step in certain system -wide changes, it is recom- accessed via a pointer. (Recall that struct and union types are 

mended that conversion declarations be marked up so that considered special kinds of classes in C++.) To facilitate the 

conversion declarations which are transitional can be dis- work of the source expander, we need only provide 'privi- 

tinguished from those which are intended to remain. For 25 leged' versions of these operators — say, "::?", ".?", and 

example, we can begin transitional conversion declarations "->?", respectively — and a compilation flag indicating 

with something like, say, whether or not such forms are permitted. 

pending convert ...[... — or — obsolete convert ...[... The issue here is that, being lexically scoped, conversion 

where "pending" means that this conversion will eventually declarations declared within a C++ class, say, would have 

be eliminated by source transition to a new form, and 30 the same privileges as other code with the class, including 

"obsolete" means that the transition is imminent — the pro- privileged access to members. However, when we expand an 

grammer should waste no time in applying the source invocation of a conversion declaration outside the class, this 

expander to these transitions. Not only does this make the privileged access is revoked. We need the 'privileged access' 

status of conversion declarations visible at a glance, but it operators to let the source expander produce a straightfor- 

allows the source expander to selectively transition invoca- 35 ward textual expansion with equivalent semantics. Of 

tions of marked conversion declarations, without requiring course, the source expander would only use the privileged 

an explicit list of which conversion declarations are to be access operators where they are actually required; all 

transitioned. accesses which could be made without them would be 

For example, consider the conversions to pre_incr expanded without them by the source expander. 

trans__countO,post_incr_trans_countO, and incr_trans_ 40 Plainly, the privileged access operators should only be 

count 0 described previously. It might well be the case that used to (1) make visible the semantics of the compiled code 

we would want eventually to modify the system's source for debugging or listing purposes or (2) support short-term 

text so that the calls to these routines were made explicitly, code patches. Uses beyond those would destroy the software 

instead of being implicit in the incrementation idiom and engineering benefits of making certain accesses privileged, 

these three conversion declarations. 45 Note that the textual expansions produced by the source 

To make the transition, we would apply the source expander are not equivalent to mere macro expansions or 
expander facility to the system's source text, identifying to textually based substitutions. All of the aforenoted weak- 
it the three relevant conversion declarations. We can identify nesses of text-based systems are still avoided when the 
the conversion declarations by any combination of the source expander is used selectively. Even wholesale use of 
following: 50 the source expander avoids many of these weaknesses. The 

1. The source _patterns which appear in them; in this case reason is that both the invocation mechanism and the 
++trans_count or trans_count++ (or parts thereof). substitution chosen remain semantically rather than textu- 

2. The result_pattems which appear in them; in this case ally based when the source expander is employed. 
pre_incr_trans_countO, post_incr__trans__countO, and Implementing Conversion Declarations and a Source 
incr_trans_countO (or parts thereof). 55 Expander 

3. A label name which we associate with them. To support What follows is a discussion of how a compiler should be 
this, the preferred syntax must be extended to permit a label, structured in order to support conversion declarations and a 
so that a conversion using a label begins with "convert source expander facility, and what additional tools are 
CD labeLname: entire mode [...". needed to support the source expander capability. 

A complication which arises in connection with use of an 60 It would be possible to have a compiler which converted 

source expander facility is visibility or access control. In C, its entire source program into internal linked data structures 

this is not an issue: opaque types are not much used. The in the form of trees, together with a symbol table and type 

only way to declare one is to use an incomplete structure, table. However, such an internal form for annotated program 

union, or enum type, declaration, such as "struct source would be excessively bulky. 

OPAQUE;", which declares a struct type named OPAQUE, 65 We can, however, compactly represent the entire source of 

with unknown members and unknown size. However, since a large program as a flat string of bytes in Polish form, as 

conversion declarations require names, including member shown in FIG. 3. 
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Polish form is a compact format for the representation of associated with that entry. (The exact implementation used 

trees, where nodes generally represent some operation or to store this information is irrelevant; it could be a list, table, 

pseudo-operation. The representation is simple: if a node has hash table, etc.). Appearance of such a bound name triggers 

a fixed 4 arity' (i.e., a fixed number of arguments or a fixed an examination of the source_patterns of the conversion 

number of inputs), it is represented as a size, followed by the 5 declarations associated with the bound name to see which, 

encoding of its operation or pseudo-operation, followed # % D y^ apply. 

immediately by the representation of its operand subtree(s) ~ ~ . , . A - . , 

r e \ i a ♦ i*« Tt. • £ u i ui 3. Conversion declarations not fitting one of the above 

(if any), from left to right. The size field makes it possible . 

to navigate the tiee swiftly. If we have to deal with nodes *"° ™ «* ^ ^ M ««> can «* disallowed, 

having many children, and we need more speed, we could 10 Thus, to convert a source code program, the processor 12, 

'index' the descendants to speed up access further. If it is under program control of the compile code 22, reads the 

v aria die, it is represented as a size, followed by the encoding source code program 20 and compares the type or name of 

of its (pseudo-) operation, followed by an operand count, a portion of source code with types and names in the symbol 

followed by the representation of its operand subtree(s) (if table 24. When a match is found, the processor, for each 

any). Each operand subtree has the same kind of represen- is conversion declaration associated with the matching type or 

tat ion; the leaf nodes are those with no further operand name, compares the source code portion with a source 

subtrees. The entire representation can easily be encoded as semantic pattern along with properties of its substitutable 

a flat sequence of bytes. The size is the number of bytes (or parts. On a match in respect of a given conversion 

other storage units, if desired) needed to encode the subtree declaration, the processor utilises the result pattern from the 

comprising the operation and its operands. 20 conversion declaration in place of the source code portion in 

Even expanded to include line number information, such gencrating ^jeet code. (In some cases it may be possible 

a representation can be about as compact as the onginal ma t the result pattern of the conversion declaration is written 

source Unhke the original source, however, it can be m object ^ ramer than mm ^ ^ ^ ^ 

designed to be almost as efficient to navigate as a normal : . ^ ... . . , , . . r . . 

. , * • * * « . 4 t - ii -r *u u merely inserts this object code m place of the source code 

pointer-linked data structure, especially if the above- 25 . J . * 

mentioned 'indexing' of nodes with man/children is used. P orUOD wben tbe P"**™-) 

The representation of a for-statement, for example, would To implement an equivalent source text facility, the com- 
be as shown in FIG. 4a where the init-exp rep is the piler should control the replacement of source text matching 
representation of the initialization expression, the text-exp a conversion declaration with new source text embodying 
rep is the representation of the loop termination text 30 the new semantics specified by the conversion declaration, 
expression, and the body-stmt rep is the representation of the All source text is exposed to the compiler, including line and 
statement which forms the body of the loop. The represen- column number information, as is the source text for all 
tation of a block with 23 statements in its body would be as source_pattems and result_pattems. The compiler can 
shown in FIG. 4b. (Note that for has a fixed count of four either emit a control file indicating how the original source 
operands, whereas block is variadic.) 35 text must ^ modified to convert it to the new source text 
Turning to FIG. 5, a computer system 10 comprises a equivalent to the semantics specified by the expanded con- 
processor 12, a memory 14 a computer media reader 16, and vcrsion declaration invocations, or can perform the changes 
a computer media store 18 (e.g., a computer diskette) storing directly 

compiler code. The memory stores a source program 20 and _ . ' , . 

the compiler code 22 uploaded from disk 18. The compiler 40 . 011 f^e whole, the way to implement the source changes 

code has a symbol table 24. The processor 12, under control ^ straightforward, but there is a potential significant com- 

of the compiler code 22, acts as a compiler. phcation: because conversion declarations are lexically 

A suitable representation for conversion declarations in lt ^ntirely possible that the meanings 

the compiler symbol table 24 uses: of b ? ,md s * n *°* at me P° ml where ^ expansion is 

1. A representation similar to that used for routines for the 45 reaped are not the same as the meanings of those bound 
handling of their parameter and access mode information. ******* me conveislOD declaraUon was declared ' 

2. Polish form for source_pattems and result_pattems, When this situation arises, its occurrence is exposed to the 
with some special encoding for references to parameters compiler. The compiler must then direct the expansion so 
such as beginning the occurrence of a parameter with an ma U not only does the required expansion occur at the 
otherwise illegal character or character sequence, and rep- 50 invocation site, but any needed subsidiary changes must be 
resenting the parameter as a numeric value stored as one made to ensure that the semantics are preserved despite the 
byte. change in scope from the point at which the result_pattern 

Conversion declaration information can be placed in the appears in the conversion declaration and the point at which 

compiler's symbol table as follows: the result__pattern is applied at the conversion declaration 

1. For each type declaring or tied to a conversion 55 invocation. 

declaration, the type information contains an enumeration of Consider a simple example: 

the various conversions associated with that type. (The exact 

implementation used to store this information is irrelevant; 

it could be a list, table, hash table, etc.). Occurrences of the ; 

type trigger an examination of the source_pattems of the 60 01 t yP cdef unsi 8» ed char tool; 

conversion declarations associated with the type to see 02 unsigned long XOI; /* ADDED: cXlra Overhead Incurred •/ 

which, if any, apply. 

2. Where a conversion declaration is not tied to a specific 03 no - val □ /•added*/ 
type, it is generally tied to the use of a particular bound name j£ to ++trans - counI; ^ rount++; 
(i.e., a name tied to certain properties) such as a global 65 06 tnms_count 4= i + XOI; 

variable or procedure definition. In these cases, the name 07 void order_update (boot xoi) /• extract Order information */{ 
table contains an enumeration of the various conversions 
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-continued 
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08 
09 



++tianB_oount; 
if (XOI) f* Handle extraction of Order Info: •/ { 



In the above source code fragment, we have a transaction 
processing system. We keep track of transactions processed 
in a variable called trans_ count. The time comes when we 
want to weight transactions which incur extra overhead 
more heavily. When this will occur, we keep the weight in 
variable XOI declared on line 02. We also write a conversion 
declaration (lines 03-06) which will modify simple incre- 
ments of trans_count to add in the value of XOI. 

The problem arises when we want to generate equivalent 
source for the routine order_update starting on line 07. It 
takes a Boolean parameter, also called XOI, in this case 
meaning: eXtract Order Information. Our expansion must 
correctly refer to the XOI declared on line 02, not the XOI 
declared on line 07. 

The solution is that the source expansion facility must 
rename one of the conflicting XOIs. Since the one declared 
on line 07 is local to the declaration of order_update, the 
most sensible choice is to rename this XOI, and to expand 
the declaration of order_update as shown below: 



07 
08 



09 



void order_update (boot zXOI) /* eXtract Order Information */{ 
trans_count += 1 + XOI; 



if (zXOI) {* Handle extraction of Order Info: 
0 
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As shown, references to the XOI declared in order_date 
become references to zXOI. The conflict has been removed, 
and line OS now performs exactly the semantics which the 
invocation of the conversion on it would have achieved. 

Modifications of the invention will be apparent to those 
skilled in the art and, therefore, the invention is defined in 
the claims. 

What is claimed is: 

1. A compiler which checks types and usages at compile 
time, comprising: 

a reader and storer for reading source code of a program 
having a type system and for, on encountering a con- 
version declaration for use in upgrading said source 
code, said conversion declaration having 
a type or bound name to which said conversion decla- 
ration is tied; 

a list of substitutable parts, with each substitutable part 50 

having a list of properties; 
a set of one or more semantic patterns including said 

substitutable parts for matching one or more portions 

of said source code which are tied to said type or 

bound name; and 
a result pattern showing what will be substituted for 

each matching portion of said source code, 
storing a representation of said conversion declaration. 

2. The compiler of claim 1 including: 
a comparator for comparing portions of said source code 

program tied to said type or bound name with said 
semantic patterns including said substitutable parts of 
said stored representation of a conversion declaration 
and, based on said comparison, selectively substituting 
said result pattern of said stored representation of a 
conversion declaration for said portions of said source 
code program. 
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3. The compiler of claim 2 wherein said bound name 
comprises a procedure or module to which said conversion 
declaration is tied. 

4. The compiler of claim 3 wherein said list of properties 
for a substitutable part comprises fixed information for 
properties that arc fixed, permissible options for properties 
that have options, and a "don't care" indicator for properties 
which may have any possible option. 

5. The compiler of claim 4 wherein said list of properties 
for a given substitutable part comprises access modes for 
said given substitutable part. 

6. The compiler of claim 5 wherein each source pattern 
comprises multiple statements. 

7. The compiler of claim 6 wherein said result partem 
comprises multiple statements. 

8. The compiler of claim 5 including an indication of an 
access mode for said source pattern. 

9. The compiler of claim 2 wherein said reader and storer 
is also for adding to properties of fixed parts of said semantic 
patterns based on placement of said conversion declaration 
in source code, whereby said conversion declaration is 
lexically scoped. 

10. A method for upgrading source code of a program of 
a type which has a type system and is statically compiled in 
a compiler which checks types and usages at compile time, 
comprising: 

reading source code of said program and for, after encoun- 
tering a conversion declaration having: 
a type, procedure, or module to which said conversion 

declaration is tied; 
a list of substitutable parts, with each substitutable part 

having a list of properties; 
a set of one or more semantic patterns having said 

substitutable parts for matching one or more portions 

of said source code tied to said type, procedure, or 

module; and 

a result pattern showing what will be substituted for 
each matching portion of said source code, 

comparing portions of said source code which are tied 
to said type, procedure, or module with semantic 
patterns in said set of one or more semantic patterns 
and with said list of substitutable parts; 

on finding a matching source code portion converting 
said matching source code portion using said result 
pattern. 

11. The method of claim 10 further comprising adding to 
properties of fixed parts of said semantic patterns based on 
placement of said conversion declaration in source code, 
whereby said conversion declaration is lexically scoped. 

12. A compiler which checks types and usages at compile 
time, comprising: 

means for reading source code of a program having a type 
system and at least one conversion declaration for use 
in upgrading said source code, said at least one con- 
version declaration having 

a type or a bound name to which said conversion 

declaration is tied; 
a list of substitutable parts, with each substitutable parts 

having a list of properties; 
a set of one or more semantic patterns having said 

substitutable parts for matching one or more portions 

of said source code tied to said type or bound name; 

and 

a result pattern showing what will be substituted for 
each matching portion of said source code, 
and for placing conversion declaration information in a 
compiler symbol table in association with said type or 
said bound name to which said conversion declaration 
is tied; and 
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means for, on encountering a type or bound name in a 
source code portion, comparing said encountered type 
or name with types and names in said symbol table and, 
on finding a matching type or name, for each conver- 
sion declaration tied to said matching type or name, 5 
comparing said set of semantic patterns having said 
substitutable parts of said each conversion declaration 
with said source code portion and on a match in respect 
of a given conversion declaration, substituting said 
result pattern of said given conversion declaration. to 

13. The method of claim 12 wherein said means for 
reading and placing is further for adding to properties of 
fixed parts of said semantic patterns based on a placement of 
said conversion declaration in source code, whereby said at 
least one conversion declaration is lexically scoped. is 

14. A computer readable medium for compiling a source 
code program, the computer readable medium executable in 
a computer system, comprising: 

means for reading source code of a program having a type 
system and at least one conversion declaration for use 20 
in upgrading said source code, said at least one con- 
version declaration having 

a type or a bound name to which said conversion 

declaration is tied; 
a list of substitutable parts, with each substitutable part 25 

having a list of properties; 
a set of one or more semantic patterns having said 

substitutable parts for matching one or more portions 

of said source code tied to said type or bound name; 

and 30 
a result pattern showing what will be substituted for 

each matching portion of said source code, 
and for placing conversion declaration information in a 
compiler symbol table in association with said type or 
said bound name to which said conversion declaration 35 
is tied; and 

means for, on encountering a type or name in a source 
code portion, comparing said encountered type or name 



with types and names in said symbol table and, on 
finding a matching type or name, for each conversion 
declaration tied to said matching type or name, com- 
paring said set of semantic patterns having said sub- 
stitutable parts of said each conversion declaration with 
said source code portion and on a match in respect of 
a given conversion declaration, substituting said result 
pattern of said given conversion declaration. 

15. The method of claim 1 wherein said means for reading 
and placing is further for adding to properties of fixed parts 
of said semantic patterns based on a placement of said 
conversion declaration in source code, whereby said at least 
one conversion declaration is lexically scoped. 

16. A system, comprising: 

a source code program having a type system and having 
at least one conversion declaration having: 
a type or a bound name to which said conversion 

declaration is tied; 
a list of substitutable parts, with each substitutable part 

having a list of properties; 
a set of one or more semantic patterns having said 

substitutable parts for matching one or more portions 

of said source code tied to said type or bound name; 

and 

a result pattern showing what will be substituted for 
each matching portion of said source code, 
a compiler which checks types and usages at compile time 
for reading source code of said program and for, after 
encountering a conversion declaration in said source 
code, comparing portions of said source code program 
with said substitutable parts and said semantic patterns 
of said encountered conversion declaration and, based 
on said comparison, selectively substituting said result 
pattern of said encountered conversion declaration for 
said portions of said source code program. 
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(57) ABSTRACT 

A software mechanism for enabling a programmer to embed 
selected machine instructions into program source code in a 
convenient fashion, and optionally restricting the 
re-ordering of such instructions by the compiler without 
making any significant modifications to the compiler pro- 
cessing. Using a table-driven approach, the mechanism 
parses the embedded machine instruction constructs and 
verifies syntax and semantic correctness. The mechanism 
then translates the constructs into low-level compiler inter- 
nal representations that may be integrated into other com- 
piler code with minimal compiler changes. When also 
supported by a robust underlying inter-module optimization 
framework, library routines containing embedded machine 
instructions according to the present invention can be inlined 
into applications. When those applications invoke such 
library routines, the present invention enables the routines to 
be optimized more effectively, thereby improving run-time 
application performance. A mechanism is also disclosed 
using a " fpreg" data type to enable floating-point arith- 
metic to be programmed from a source level where the 
programmer gains access to the full width of the floating- 
point register representation of the underlying processor. 
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PROGRAMMATIC ACCESS TO THE WIDEST 
MODE FLOATING-POINT ARITHMETIC 
SUPPORTED BY A PROCESSOR 

TECHNICAL FIELD OF THE INVENTION 

This invention relates generally to the compilation of 
computer code performing floating-point arithmetic opera- 
tions on floating-point registers, and more particularly to 
enabling, via a new data type, access in source code to the 
full width of the floating point register representation in the 
underlying processor. 

BACKGROUND OF THE INVENTION 

Source-level languages like C and C++ typically do not 
support constructs that enable access to low-level machine- 
instructions. Yet many instruction set architectures provide 
functionally useful machine instructions that cannot readily 
be accessed from standard source-level constructs. 

Typically, programmers, and notably operating system 
developers, access the functionality afforded by these spe- 
cial (possibly privileged) machine-instructions from source 
programs by invoking subroutines coded in assembly 
language, where the machine instructions can be directly 
specified. This approach suffers from a significant perfor- 
mance drawback in that the overhead of a procedure call/ 
return sequence must be incurred in order to execute the 
special machine instruction(s). Moreover, the assembly- 
coded machine instruction sequence cannot be optimized 
along with the invoking routine. 

To overcome the performance limitation with the assem- 
bly routine invocation strategy, compilers known in the art, 
such as the Gnu C compiler ("gcc"), provide some rudimen- 
tary high-level language extensions to allow programmers to 
embed a restricted set of machine instructions directly into 
their source code. In fact, the 1990 American National 
Standard for Information Systems — Programming Lan- 
guage C (hereinafter referred to as the "ANSI Standard") 
recommends the "asm" keyword as a common extension 
(though not part of the standard) for embedding machine 
instructions into source code. The ANSI Standard specifies 
no details, however, with regard to how this keyword is to 
be used. 

Current schemes that employ this strategy have draw- 
backs. For instance, gcc employs an arcane specification 
syntax. Moreover, the gcc optimizer does not have an innate 
knowledge of the semantics of embedded machine instruc- 
tions and so the user is required to spell out the optimization 
restrictions. No semantics checks are performed by the 
compiler on the embedded instructions and for the most part 
they are simply "passed through** the compiler and written 
out to the target assembly file. 

Other drawbacks of the inline assembly support in current 
compilers include: 

(a) lack of functionality to allow the user to specify 
scheduling restrictions associated with embedded 
machine instructions. This functionality would be par- 
ticularly advantageous with respect to privileged 
instructions. 

(b) imposition of arbitrary restrictions on the kind of 
operands that may be specified for the embedded 
machine instructions, for example: 

the compiler may require operands to be simple pro- 
gram variables (where permitting an arbitrary arith- 
metic expression as an operand would be more 
advantageous); and 
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the operands may be unable to refer to machine-specific 
resources in a syntactically natural manner. 

(c) lack of functionality to allow the programmer to 
access the full range and precision of internal floating- 
point register representations when embedding 
floating-point instructions. This functionality would 
simplify high-precision or high-performance floating- 
point algorithms. 

(d) imposition of restrictions on the ability to inline 
library procedures that include embedded machine 
instructions into contexts where such procedures are 
invoked, thereby curtailing program optimization 
effectiveness. 

In addition, when only a selected subset of the machine 
opcodes are permitted to be embedded into user programs, 
it may be cumbersome in current compilers to extend the 
embedded assembly support for other machine opcodes. In 
particular, this may require careful modifications to many 
portions of the compiler source code. An extensible mecha- 
nism capable of extending embedded assembly support to 
other machine opcodes would reduce the number and com- 
plexity of source code modifications required. 

It would therefore be highly advantageous to develop a 
compiler with a sophisticated capability for processing 
machine instructions embedded in high level source code. A 
"natural** specification syntax would be user friendly, while 
independent front-end validation would reduce the potential 
for many programmer errors. Further, it would be advanta- 
geous to implement an extensible compiler mechanism that 
processes source code containing embedded machine 
instructions where the mechanism is smoothly receptive to 
programmer-defined parameters indicating the nature and 
extent of compiler optimization permitted in a given case. A 
particularly useful application of such an improved compiler 
would be in coding machine-dependent "library** functions 
which would otherwise need to be largely written in assem- 
bly language and would therefore not be subject to effective 
compiler optimization, such as inlining. 

In summary, there is a need for a compiler mechanism that 
allows machine instructions to be included in high-level 
program source code, where the translation and compiler 
optimization of such instructions offers the following advan- 
tageous features to overcome the aboveKlescribed shortcom- 
ings of the current art: 

a) a "natural** specification syntax for embedding low- 
level hardware machine instructions into high-level 
computer program source code. 

b) a mechanism for the compiler front-end to perform 
syntax and semantic checks on the constructs used to 
embed machine instructions into program source code 
in an extensible and uniform manner, that is indepen- 
dent of the specific embedded machine instructions. 

c) an extensible mechanism that minimizes the changes 
required in the compiler to support additional machine 
instructions. 

d) a mechanism for the programmer to indicate the degree 
of instruction scheduling freedom that may be assumed 
by the compiler when optimizing high-level programs 
containing certain types of embedded machine instruc- 
tions. 

e) a mechanism to "inline" library functions containing 
embedded machine instructions into programs that 
invoke such library functions, in order to improve the 
run-time performance of such library function 
invocations, thereby optimizing overall program 
execution performance. 
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Such features would gain yet further advantage and utility understood by the compiler back-end in a manner that is 

in an environment where inline assembly support could gain independent of the specific characteristics of the machine 

access to the full width of the floating point registers in the instruction being inlined. 

target processor via specification of a corresponding data The inline assembly intrinsics are "lowered" by the corn- 
type in source code. 5 piler front end into a built-in function-call understood by the 

code generation phase of the compiler. The code generator 

SUMMARY OF THE INVENTION in turn expands the intrinsic into the corresponding machine 

rn ■ .* j f . ,. . . instruction which is then subjected to low-level optimiza- 

These and other objects and Features are achieved by one J r 

embodiment of the present invention which comprises the ' t . , . . . , . . . - 4 - . 

c „ r r 10 An automated table-dnven approach is used to facilitate 

tollowinii* * * 

both syntax and semantic checking of the inline assembly 

1. A general syntax for embedding or "miming" machine intrinsics as well as the translation of the intrinsics into 
(assembly) instructions into source code. For each machine actual mach ine instructions. The table contains one entry for 
instruction that is a candidate for source-level inlining, an each mtrms ic, with the entry describing characteristics of 
"intrinsic" (built-in subroutine) is defined. A function pro- 15 mat mtrinsiC) such ^ its name and the name and data types 
totype is specified for each such mtrinsic with enumerated of me required opcode arguments and return value (if any), 
data types used for instruction completers. The function ^ well ^ otber information relevant to translating the 
prototype is of the following general form: intrinsic into a low-level machine instruction. 

- *. . . . . . . a The table is used to generate (1) a file that documents the 

opcode__result=_^Asio_opcode (opcode_aigumcnt_listf, serial- . ° y ' . , . 

ization_constrai nt_spccificr J 20 mtrmsics for user programmers (includmg their function 

prototypes) (2) a set of routines invoked by the compiler 

where _^\sm_opcode is the name of the intrinsic function front-end to parse the supported inline assembly intrinsics 

(with the "opcode" portion of the name replaced with the and (3) a portion of the compiler back-end that translates the 

opcode mnemonic). Opcode completers, immediate source built-in function-call corresponding to each intrinsic into the 

operands, and register source operands are specified as 25 appropriate machine instruction. 

arguments to the intrinsic and the register target operand (if This table-driven approach requires very few, if any, 

applicable) corresponds to the "return value" of the mtrinsic. changes to the compiler when extending source-level inline 

The data types for register operands are defined to match assembly capabilities to support the embedding of additional 

the requirements of the machine instruction, with the com- machine instructions. It is usually sufficient just to add a 

piler performing the necessary data type conversions on the 30 description of the new machine instructions to the table, 

source arguments and the return value of the "inline- re-generate the derived files, and re-build the compiler, so 

assembly" intrinsics, in much the same way as for any long as the low-level components of the compiler support 

user-defined prototyped function. the emission of the new machine instructions. 

Thus, the specification syntax for embedding machine 3. Where supported by a cross-module compiler optimi- 

instructions in source code is quite "natural" in that it is very 35 zation framework, a mechanism to capture the intermediate 

similar to the syntax used for an ordinary function call in representation into a persistent format enables cross-module 

most high-level languages (e.g. C, C++) and is subject to optimization of source-code containing embedded machine 

data type conversion rules applicable to ordinary function instructions. In particular, library routines with embedded 

calls. machine instructions can themselves be "inlined" into the 

Further, the list of arguments for the machine opcode is 40 calling user functions, enabling more effective, context- 
followed by an optional instruction serialization_ sensitive optimization of such library routines, resulting in 
constraint_specifier. This feature provides the programmer improved run-time performance of applications that invoke 
a mechanism to restrict, through a parameter specified in the library routines. This feature is highly advantageous, for 
source code, compiler optimization phases from re-ordering instance, in the case of math library routines that typically 
instructions across an embedded machine instruction. 45 need to manipulate aspects of the floating-point run-time 

This feature is highly advantageous in situations where environment through special machine instructions, 

embedded machine instructions may have implicit side- The inventive machine instruction inlining mechanism is 

effects, needing to be honored as scheduling constraints by also advantageously used in conjunction with a new data 

the compiler only in certain contexts known to the user. This type which enables programmatic access to the widest mode 

ability to control optimizations is particularly useful for 50 floating-point arithmetic supported by the processor. As 

operating system programmers who have a need to embed noted in the previous section, inline support in current 

privileged low-level "system" instructions into their source compilers is generally unable to access the full range and 

code. precision of internal floating-point register representations 

Serialization_constraint_specifiers are predefined into when embedding floating-point instructions. Compiler 
several disparate categories. In application, the 55 implementations typically map source-level floating-point 
serialization_constraint__specifier associated with an data types to fixed-width memory representations. The 
embedded machine instruction is encoded as a bit-mask that memory width determines the range and degree of precision 
specifies whether distinct categories of instructions may be to which real numbers can be represented. So, for example, 
re-ordered relative to the embedded machine instruction to an 8-byte floating-point value can represent a larger range of 
dynamically execute either before or after that embedded 60 real numbers with greater precision than a corresponding 
machine instruction. The serialization constraint specifier is 4-byte floating-point value. On some processors, however, 
specified as an optional final argument to selected inline floating-point registers may have a larger width than the 
assembly intrinsics for which user-specified optimization natural width of source-level floating-point data types, 
control is desired. When this argument is omitted, a suitably allowing for intermediate floating-point results to be corn- 
conservative default value is assumed by the compiler. 65 puted to a greater precision and numeric range; but this 

2. A mechanism to translate the source-level inline assem- extended precision and range is not usually available to the 
bly intrinsics from the source-code into a representation user of a high-level language (such as C or C++). 
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Id order to provide access to the full width of the floating FIG. 4 illustrates use of inline assembly descriptor table 

point registers for either ordinary floating-point arithmetic or 301 to generate a library of low-level object files available 

for inline assembly constructs involving floating-point to assist translation of intrinsics from a high level interme- 

operands, therefore, a oew built-in data type is also disclosed diate representation of code to a low level intermediate 

herein, named "_fpreg" for the C programming language, 5 representation thereof; 

corresponding to a floating point representation that is as FIG. 5 illustrates use of inline assembly descriptor table 

wide as the floating-point registers of the underlying pro- 301 to create a library to assist front-end validation of 

cessor. Users may take advantage of the new data type in intrinsics during the compilation thereof; 

conjunction with the disclosed methods for the embedding mG 6 illustrates me language-independent nature of file 

of a machine instruction by using this data type for the 10 and horary generadon m accordajM^ with the present inven- 

parameters and/or return value of an intrinsic that maps to a ^ on . aiK j 

floating-point machine indmclion FIG. 7 illustrates an application of the present invention, 

It is therefore a technical advantage of the present nwen- whefe CTOSS . module optimization aDd fo^g is supported, 

ton to enable a flexible, easy to understand language- ^ ^ ^^^^ lib routin J "(suchTmath 

compauble syntax for embedding or mining machine 15 access , ow . level mac J ne and still 

instructions into source code. „ v . . . , . . ^ 

T . - . A . . , , A _ . . allow such routines to be mlined into user applications. 
It is a further technical advantage of the present invention 

,to enable the compiler to perform semantic checks on the DESCRIPTION OF THE PREFERRED 

embedded machine instructions that are specified by invok- EMBODIMENTS 

ing prototyped intrinsic routines, in much the same way that 20 _ __ m . , „ . 

semantic checks are performed on calls to prototyped user .„ Turmn f ^ to a typical compilation process is 

routines illustrated upon which a preferred embodiment of the 

It is a still further technical advantage of the present P 1 ^ 01 invention ma Y be enabled. The compiler transforms 

invention to enable inline assembly support to be extended program on ***** through several 

to new machine instructions in a streamlined manner that 25 ^presentations. Source code 101 is a representation created 

greatly minimizes the need to modify compiler source code. b y me Programmer. Front-end processing 102 transforms 

It is a yet further technical advantage of the present code 101 ml ° a high-level intermediate representa- 

invention to enable uncontrolled optimization of embed- Uo ° 103 ™ min the * this high-level inter- 

ded low-level "system" machine instructions. mediate slage, the associated high-level intermediate repre- 

It is another technical advantage of the present invention 30 sentaUon 103 rs advantageously (although not mandatorily) 

to enable, where supported, cross-module optimizations, P asscd ihrou & high-level optimizer 104 to translate the 

notably inlining, of horary routines that contain embedded ^Presentation into a more efficient high-level intermediate 

machine instructions representation. Code generator 105 then translates high- 

Another technical advantage of the present invention is, lev ^! intermediate representation 103 into low-level inter- 
when used in conjunction with the new _fpreg data type 35 mediate representation 106, whereupon a low-level opti- 
also disclosed herein, to support and facilitate reference to °"f . r 107 translates low-level intermediate reputation 
floating-point machine instructions in order to provide J 06 ™\° aD effitnent ^f* representanon 1(W mat can 
access to the hill width of floating-point registers provided be hn ^ d ™* a machine-executable program. It will be 
bv a processor appreciated that some compilers are known in the art in 

The foregoing has outlined rather broadly the features and 40 whic h front-end and code generation stages 102 and 105 are 

technical advantages of the present invention in order that ™nb™d (removing the need for high-level mtermediate 

the detailed description of the invention that follows may be representation 103), and m others, the code generation and 

better understood. Additional features and advantages of the ow - level qphmiajg stages 105 and 107 are combined 

invention will be described hereinafter which form the (removing the need for low-level intermediate representa- 

subject of the claims of the invention. It should be appre- 45 Uon 106 > 0ther compilers are known that add additional 

ciated by those skilled in the art that the conception and the representations and translation stages. Within this basic 

specific embodiment disclosed may be readily utilized as a framework, however, the present invention may be enabled 

basis for modifying or designing other structures for carry- on anv compiler performing substanUally the 

ing out the same purposes as the present invention. It should sXt ^ Ascribed on FIG. 1. 

also be realized by those skilled in the art that such equiva- 50 with reference now to FIG. 2, the source level specifica- 

lent constructions do not depart from the spirit and scope of tion features of the present invention will now be discussed, 

the invention as set forth in the appended claims. 11 ™^ he appreciated that consistent with earlier disclosure 

in the background and summary sections set forth above, the 

BRIEF DESCRIPTION OF THE DRAWINGS present invention provides a mechanism by which machine 

5S instructions may be embedded into source code to enable 

For a more complete understanding of the present improved levels of smoom and effident compilation thereof, 

invention, and the advantages thereof; reference is now advant ageousIy responsive to selected optimization restric- 

made to the following descriptions taken in conjunction with ^ ordamed by the programmer. 

the accompanying drawings, in which. ^ a preferred embodiment herein, the invention is 
FIG. 1 illustrates a typical compiler system in which the ^ enabled on compilation of C source code. It will be 
present invention may be enabled; appreciated, however, that use of the C prograinming lan- 
FIG. 2 illustrates the availability of an inline assembly guage in this way is exemplary only, and that the invention 
intrinsic header file ("inline.h") SH^ as a system header file may be enabled analogously on other high-level program- 
containing intrinsics through which machine instructions ming languages, such as C++ and FORTRAN, without 
may be inlined in accordance with the present invention; 65 departing from the spirit and scope of the invention. 

FIG. 3 illustrates use of inline assembly descriptor table Turning now to FIG. 2, it should be first noted that blocks 

301 to generate the "inline.h" system header file; 202, 203 and 204 are explanatory labels and not part of the 
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overall flow of information illustrated thereon. On FIG. 2, An operand that corresponds to a dedicated machine 
machine instructions are embedded or "inlined" into C register (source or target) may be specified using an appro- 
source code 201, by the user, through the use of "built-in" priate symbolic constant. Such symbolic constants are typi- 
pseudo- function (or "intrinsic") calls. Generally, programs cally defined in the "inline .h" system header file discussed 
that make intrinsic calls may refer to and incorporate several 5 above with reference to FIG. 2. An immediate operand is 
types of files into source code 201., such as application specified as a simple integer constant and generally should 
header files AH 1 -AH n , or system header files SHj-SH^. In be no larger than the corresponding instruction field width, 
the exemplary use of C source code described herein, the To be compatible, a source language expression having a 
present invention is enabled through inclusion of system scalar data type must be specified as the argument corre- 
header file SH 2 on FIG. 2, namely an inline assembly 10 sponding to a general purpose or floating-point register 
intrinsic header file (see label block 202). The file is sped- source operand. In particular, a general purpose register 
fied as set forth below in detail so that, when included in source operand must be specified using an argument expres- 
source code 201„ the mechanism of the present invention s j on that has an arithmetic data type (i.e. integral or floating- 
will be enabled. p 0mt type). An operand may nonetheless be of any type 

Note that as shown on FIG. 2, the inline assembly intrinsic 15 within this requirement for compatibility. For example, an 

header file SH 2 (named "inline.h" on FIG. 2 to be consistent operand may be a simple variable, or alternatively it may be 

with the convention on many UNIX®-based systems) typi- an arithmetic expression including variables, 

cally contains declarations of symbolic constants and intrin- Typically, the compiler will convert the argument value 

sic function prototypes (possibly just as comments), and for a general-purpose register source operand into an 

typically resides in a central location along with other 20 ^1^^ integer value as wide as the register width of the 

system header files SH^H,,. The "inline.h" system header target machine (e.g. 32-bits or 64-bits). 

file SH 2 may then be included" by user programs that where a general-purpose register operand clearly corre- 

embed machine instructions into source code, enabling the ^ to a m address, an argument value having a 

use of _Asm_opcode mtnnsics. pointer type may be required. 

With reference to FIG. 3, it wiU be seen that a software * Any generd purpose or floating-pomt register target oper- 

tool 302 advantageously generates "inhne.h system header and vahie defined 5 an ^ assembly instruction is treated 

file SH 2 from an inline assembly descriptor table 301 at the ^ me retura va]ue of the ^sm_opcode pseudo-function 

time the compiler product is created. This table-driven ca yj 

approach is described in more detail later. * - . , 

t> ^ ♦ * nr* „ ... . « . . . 30 A general-purpose register target operand value is typi- 

Returning to FIG. 2, when an inline assembly intrinsic cally ^ d „ an unsigned integer that is as wide as the 

header file specified in accordance with the present mven- register-width of the target architecture (e.g. 32-bits or 

tion is included in a user program processing continues to ^fore, the pseudo-function return value will be 

convert source code 201, into object code 201 o in the su5ject to ^ normal type conversions associated with an 

manner illustrated on HG. 1. ordinary call to a function that returns an unsigned integer 

****** value. 

The general syntax for the pseudo-function call/intrinsic „, ... . 

call in C is as follows- avoid potential loss of precision when operating on 

floating-point values, however, floating-point register target 

opcode_rcsult-_Asm_opcodc (<oomplctcr__list>, <opcrnnd_ and source operands of embedded machine instructions in a 

lisb^^riaiizatioi^constmn^l); 40 preferred embodiment are allowed to be as wide as the 

A unique built-in function name (denoted above as floating-point register- width of the target architecture. For 

_Asm_opcode) is defined for each assembly instruction architectures where the floating-point register- width exceeds 

that can be generated using the inline assembly mechanism. the natural memory-width of standard floating-point data 

The inline assembly instructions may be regarded as exter- types (e.g. the "float" and "double" standard data types in the 

nal functions for which implicit external declarations and 45 C language), the new "_jpreg" data type may be used to 

function definitions are provided by the compiler. These declare the arguments and return value of inline assembly 

intrinsics are not declared explicitly by the user programs. intrinsics used to embed floating-point instructions into 

Moreover, the addresses of the inline assembly intrinsics source code. As explained in more detail elsewhere in this 

may not be computed by a user program. disclosure, the "_fpreg" data type corresponds to a floating- 

The "_Asm__opcode" name is recognized by the com- 50 point representation that is as wide as the floating-point 

piler and causes the corresponding assembly instruction to registers of the target architecture. 

be generated. In general, a unique __Asm_opcode name is The following examples illustrate the source code speci- 

defined for each instruction that corresponds to a supported fication technique of the present invention as described 

inline assembly instruction. immediately above: 

The first arguments to the __Asm_opcode intrinsic call, 55 _ _ __ _ 

denoted as <completer_list> in the general syntax 0 For an ADET machine instruction of the form: 
description, are symbolic constants for all the completers 
associated with the opcode. The inline assembly opcode 

completer arguments are followed by the instruction whefe fl a ^ f3 nd to ^ gener a]-purpose 

operands, denote^ as <operand_hst> in the general syntax 60 macmne registere> ^ fj&nx prototype for the inline 

descnption, which are specified id order according to pro- can 1* defined as foltows: 
toco Is denned by particular instruction set architectures. 

Note that if an embedded machine instruction has no UInt64 __Asm^ADD (Ulnt64 r2, Ulnt64 r3) 

completers, then the <completer_list> and its following where "UInt64" corresponds to a 64-bit unsigned integer 

comma is omitted. Similarly, if the embedded machine 65 data-type. 

instruction has no operands, then the <operand_list> and its The ADD machine instruction can then be embedded into 

preceding comma is omitted a "C" source program as follows: 



ADD rl-c2, r3 
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tfinclude <anline.h> 
inl gl, g2, g3; 
main ( ) 
{ 

gl - _Asm_jU)D (g2, g3); 

} 



I* global integer variables 7 



ii) For a "LOAD" machine instruction of the form: 



LOAD. 



Iuc={mcm__addr] 



where 

<size> is an opcode completer encoding the bit-size of the 
object being loaded which may be one of "b" (for byte 
or 8-bits), "hw" (for half-word or 16-bits) or "word" 
(for word or 32-bits), 
"value** corresponds to a 32-bit general-purpose machine 
register whose value is to be set by the load instruction 
"mem_addr** corresponds to a 32-bit memory address 
that specifies the starting location in memory of the 
object whose value is to be loaded into "value" 
the function prototype for the inline intrinsic can be defined 
as follows: 

UInt32 __Asm_LOAD (_Asm_size size, void*mem_addr) 

where "UInt32" corresponds to a 32-bit unsigned integer 
data-type, "void*" is a generic pointer data type, and 
"_Asm_size" is a enumeration type that encodes one of 3 
possible symbolic constants. For example, in the C 
language, _Asm_size may be defined as follows: 
typedef enum { 

_b=l, 

_hw-2, 

_w-3 
} _ J Asm_size; 

Alternatively, _Asm_size may be defined to be a simple 
integer data type with pre-defined symbolic constant values 
for each legal LOAD opcode completer. Using language 
neutral "C* pre -processor directives, 

^define _b (1) 

^define _Jiw (2) 

#define _w (3) 

Note that the declarations associated with "_Asm_size" 
would be placed in the "inline .h" system header file, and 
would be read in by the compiler when parsing the source 
program. 
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integer mask value encodes what types of (data independent) 
instructions may be moved past the inline assembly opcode 
in either direction in a dynamic sense (i.e. before to after, or 
after to before) in the current function body. If omitted, the 
compiler will use a default serialization mask value. For the 
purposes of specifying serialization constraints in a pre- 
ferred embodiment, the instruction opcodes may 
advantageously, but not mandatorily, be divided into the 
following categories: 

1. Memory Opcodes: load and store instructions 

2. ALU Opcodes: instructions with general-purpose reg- 
ister operands 

3. Floating-Point Opcodes: instructions with floating- 
point register operands 

4. System Opcodes: privileged "system" instructions 

5. Branch: "basic block** boundary 

6. Call: function invocation point 

With respect to serialization constraints, an embedded 
machine instruction may act as a "fence" that prevents the 
scheduling of downstream instructions ahead of it, or a 
"fence" that prevents the scheduling of upstream instruc- 
tions after it. Such constraints may be referred to as a 
"downward fence" and "upward fence** serialization 
constraint, respectively. Given this classification, the serial- 
ization constraints associated with an inline system opcode 
can be encoded as an integer value, which can be defined by 
ORing together an appropriate set of constant bit-masks. For 
a system opcode, this encoded serialization constraint value 
may be specified as an optional final argument of the 
_^Asm_opcode intrinsic call. For example, for the C 
language, the bit-mask values may defined to be enumera- 
tion constants as follows: 



35 



40 



45 



typedef enum { 




_NO_FENCE 


-0x0, 


_UP_MEM_FENCE 


- 0x1, 


_UP_ALU_FENCE 


-0x2, 


_UP_FLOP_FENCE 


-0x4, 


_UP_SYS_FENCE 


-0x8, 


_UP_CALU_FENCE 


-0x10, 


_UP_BR_FENCE 


-0x20, 


_POWN_MEM_FENCE 


-0x100, 


_DOWN_jVLU_J?ENCE 


-0x200, 


_JX)WN_FLOP_JENCE 


= 0x400, 


_DOWN_SYS_FENCE 


-0x800, 


— DOWN_CAlX__FENCE 


= 0x1000, 


_DOWN_ - BR_FENCE 


= 0x2000 


} wAsm_fence; 





The LOAD machine instruction can then be embedded 50 (Note: The _j\sm_fence definition would advantageously 



into a "C" program thusly: 



#include <inline.h> 
inl g; 
inl *p ; 



f* global integer variable */ 
/* global integer pointer variable ' 



g - _Asm_LOAD(_w, p); 



Certain inline assembly opcodes, notably those that may 
be considered as privileged "system" opcodes, may option- 
ally specify an additional argument that explicitly indicates 
the constraints that the compiler must honor with regard to 
instruction re-ordering. This optional "serialization con- 
straint" argument is specified as an integer mask value. The 



be placed in the "inline.h** system header file.) 

So, for example, to prevent the compiler from scheduling 
floating-point operations across an inlined system opcode 
that changes the default floating-point rounding mode, a 
55 programmer might use an integer mask formed as (_UP_ 
FLOP_FENCE|_DOWN__FLOP_FENCE). 

The _UP_J3R_FENCE and __DOWN_BR_FENCE 
relate to "basic block" boundaries. (A basic block corre- 
sponds to the largest contiguous section of source code 
60 without any incoming or outgoing control transfers, exclud- 
ing function calls.) Thus, a serialization constraint value 
formed by ORing together these two bit masks will prevent 
the compiler from scheduling the associated inlined system 
opcode outside of its original basic block. 
65 Note that the compiler must automatically detect and 
honor any explicit data dependence constraints involving an 
inlined system opcode, independent of its associated serial- 
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ization mask value. So, for example, just because an inlined (a) The name of the intrinsic 

system opcode intrinsic call argument is defined by an (b) A brief textual description of the intrinsic 

integer add operation, it is not necessary to explicitly specify , . N , f , intrinsic wrumente fif amrt 

the _UP_ALU_FENCE bit-mask as part of the serializa- K ) 311(1 lypeS 01 tne 1011113510 arguments (it any; 

tion constraint argument 5 < d ) Name md of lbe intrinsic retum value (* »y) 

The serialization constraint integer mask value may be ( c ) With momentary reference back to FIG. 1, additional 

treated as an optional final argument to the inline system information for code generator 105 to perform the 

opcode intrinsic invocation. If this argument is omitted, the translation from high level intermediate representation 

compiler may choose to use any reasonable default serial- 103 to low level intermediate representation 106 

ization mask value (e.g. 0x3D3D — full serialization with all 10 11 ™& appreciated that this table-driven approach 

other opcode categories except ALU operations). Note that enables the separation of the generation of the assembly 

if a system opcode instruction is constrained to be serialized intrinsic header file, parsing support library, and code gen- 

with respect to another instruction, the compiler must not eration utilities from the compiler's mainstream compilation 

schedule the two instructions to execute concurrently. processing. Any maintenance to the table may be made (such 

To specify serialization constraints at an arbitrary point in 15 as adding to the list of supported inlined instruction) without 
a program, a placeholder inline assembly opcode intrinsic affecting the compiler's primary processing functionality, 
named _Asm_sched_Jence may be used. This special This makes performing such maintenance easy and predict- 
in trinsic just accepts one argument that specifies the serial- able. The table-driven approach is also user programming 
ization mask value. The compiler will then honor the seri- language independent, extending the versatility of the 
alization constraints associated with this placeholder 20 present invention. 

opcode, but omit the opcode from the final instruction On a more detailed level, at least three specific advantages 

stream. are offered by this table-driven approach: 

The scope of the serialization constraints is limited to the 

function containing the inlined system opcode. By default, L Header Flle Generation 

the compiler may assume that called functions do not 25 The table facilitates generation of a file that documents 

specify any inlined system opcodes with serialization con- intrinsics for user programmers, providing intrinsic function 

straints. However, the _Asm_sched_Jencc intrinsic may prototypes and brief descriptions. Using table elements (a), 

be used to explicitly communicate serialization constraints ( c ) (d) as itemized above, and with reference again 

at a call-site that is known to invoke a function that executes to me preceding discussion accompanying FIG. 3, a soft- 

a serializing system instruction. 30 ware tool 302 generates an "inline.h" system header SH 2 

EXAMPLE from inline assembly descriptor table 301. Furthermore, 

n . . . „ . x - - , "inline.h** system header SH, also defines and contains an 

If a flush cache .n^ctionCFC" opcode) k a prmleged ettluaBaled J fKA of symbolic < £ BStan|s> regist6I5> 

machine UBtrucUon that is to be embedded into source code andso fortb ^ ^ programm6r may Jfas legal operands 

and one that should allow user-specified serialization 3S ^ ^ ^ c ^ ' ^ £ 
constraints, lbe following innne assembly intrude may be 

in cases where an operand is a numeric constant, 

e ne * "inline .h" system header SH 2 documents the range of legal 

void _Asm__FC (fseriaiizatioa_ccmstraiiit_5pccificrl) values for the operand, which is checked by the compiler. 

where the return type of the intrinsic is declared to be "void" _ „ _ _ _ 

to indicate that no data value is defined by the machine 40 2 " Paisin S Generatlon 

instruction. The table facilitates generation of part of a library that 

Now the FC instruction may be embedded in a C program assists, with reference again now to FIG. 1, front end 

with serialization constraints that prevent the compiler from processing ("FE") 102 in recognizing intrinsics specified by 

re-ordering memory instructions across the FC instruction as the programmer in source code 101, validating first that the 

shown below: programmer has written such intrinsics legally, and then 

translating the intrinsics into high-level intermediate repre- 
sentation 103. 

ttndude <iniinc.h> Note that in accordance with the present invention, it 

int gi, g2; /• global integer variables 7 50 would also be possible to generate intrinsic-related front-end 

main() processing directly. In a preferred embodiment, however, 

f n „ . ., library functionality is used. 

gl = 0; /* can't be moved after FC instruction */ J . J 

_^m_J^_UP_MEMORY_jwcE|ix>^ Table-driven front-end processing enables an advanta- 

g2 = i; /* can't be moved before FC instruction */ geous feature of the present invention, namely the automatic 

| 55 syntax parsing and semantics checking of the user's inline 

assembly code by FE 102. This feature validates that code 
Note that the _j\sm_FC instruction specifies memory containing embedded machine instructions is semantically 
fence serialization constraints in both directions preventing correct when it is incorporated into source code 101 in the 
the re-ordering of the stores to global variables gl and g2 same way that a front end verifies that an ordinary function 
across the FC instruction. 60 invocation is semantically correct- This frees other process- 
Use of Table-driven Approach ing units of the compiler, such as code generator 105 and 
A table-driven approach is advantageously used to help low level optimizer 107, from the time-consuming task of 
the compiler handle assembly intrinsic operations. The table error checking. 

contains one entry for each intrinsic, with the entry describ- This front-end validation through reference to a partial 

ing the characteristics of that intrinsic. In a preferred 65 library is enabled by generation of a header file as illustrated 

embodiment, although not mandatorily, those characteristics on FIGS. 5 and 6. Turning first to FIG. 5, in which it should 

may be tabulated as follows: again be noted that blocks 506, 507 and 508 are explanatory 
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items and not part of the information flow, inline assembly 
descriptor table 301 provides elements (a), (c) and (d) as 
itemized above to software tool 501. This information 
enables software tool 501 to generate language-independent 
inline assembly parser header file ("asmp.h"), which may 
then be included into corresponding source code "asmp.c" 
503 and compiled 504 into corresponding object code 
"asmp.o" 505. It will thus be seen from FIG. 5 that "asmp.o" 
505 is a language-independent inline assembly parser library 
object file in a form suitable for assisting FE 102 on FIG. 1. 

With reference now to FIG. 6, it will be seen that 
" inline. h" system header SHj provides legal intrinsics for a 
programmer to invoke from source code 601. On FIG. 6, 
exemplary illustration is made of C source code 601^ C++ 
source code 601^,, and FORTRAN source code 601^ 
although the invention is not limited to these particular 
programming languages, and will be understood to be also 
enabled according to FIG. 6 on other programming lan- 
guages. It will be noted that each of the illustrated source 
codes 601 c , 601p and 601^ have compiler operations and 
sequences 601-608 analogous to FIG. 1. Further, "asmp.o" 
library object file 505, being language independent, is uni- 
versally available to C FE 602 c , C++ FE 602^ and FOR- 
TRAN FE 602^- to assist in front-end error checking. Front 
end processing FE 602 does this checking by invoking 
utility functions defined in "asmp.o" library object file 505 
to ensure that embedded machine instructions encountered 
in source code 601 are using the correct types and numbers 
of values. This checking is advantageously performed 
before actual code for embedded machine instructions is 
generated in high-level intermediate representation 603. 

In this way, it will be appreciated that various potential 
errors may be checked in a flexible, table-driven manner that 
is easily maintained by a programmer. For example, errors 
that may be checked include: 

whether the instruction being inlined is supported. 

whether the number of arguments passed is correct. 

whether the arguments passed are of the correct type. 

whether the values of numeric integer constant 40 
arguments, if any, are within the allowable range. 

whether the serialization constraint specifier is allowed 
for the specified instruction. 

Furthermore, the table also allows the system to compute 
the default serialization mask for the specified instruction if 
one is needed but not supplied by the user. 
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3. Code Generation 

The table 301 facilitates actual code generation (as shown 
on FIG. 1) by assisting CG 105 in translation of high level 
intermediate representation ("HIL") 103 to low level inter- 
mediate representation ("UL") 106. Specifically, the table 
assists CG 105 in translating intrinsics previously incorpo- 
rated into source code 101. The table may also, when 
processed into a part of CG 105, perform consistency 
checking to recognize certain cases of incorrect HIL 103 that 
were not caught by error checking in front end processing 
("FE") 102. 

Note that according to the present invention, it would also 
be possible to generate a library of CG object files to assist 
CG 105 in processing intrinsics, similar to library 505 that 
assists FE 102, as illustrated on FIG. 5. Turning now to FIG. 
4, and again noting that blocks 405 and 406 are explanatory 
items and not part of the information flow, inline assembly 
descriptor assembly table 301 provides elements (c), (d) and 
(e) as itemized above to software tool 400. Using this 
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information, software tool 400 generates CG source file 
401j, which in turn is compiled along with ordinary CG 
source files 401 2 -401„ (blocks 402) into CG object files 
403 2 -403 n . Archiver 404 accumulates CG object files 
403j-403„ into CG library 407. 

In more detail now, the foregoing translation from HIL 
103 to UL 106 for intrinsics includes the following phases: 

A. Generation of data structures 

Automation at compiler-build time generates, for each 
possible intrinsic operation, a data structure that 
contains information on the types of the intrinsic 
arguments (if any) and the type of the return value (if 
any). 

B. Consistency checking 

At compiler-run time, a portion of CG that performs 
consistency checking on intrinsic operations can 
consult the appropriate data structure from A imme- 
diately above. This portion of CG does not need to be 
modified when a new intrinsic operation is added, 
unless the language in which the table 301 is written 
has changed. 

C. Translation from HIL to LIL 

Most intrinsic operations can be translated from HIL to 
LIL automatically, using information from the table. 
In a preferred embodiment, an escape mechanism is 
also advantageously provided so that an intrinsic 
operation that cannot be translated automatically can 
be flagged to be translated later by a hand-coded 
routine. The enablement of the escape mechanism 
does not affect automatic consistency checking. 
The representation of an intrinsic invocation in HIL 
identifies the intrinsic operation and has a list of arguments; 
there may be an implicit return value. The representation of 
an intrinsic invocation in LIL identifies a low-level operation 
and has a list of arguments. The translation process must 
retrieve information from the HIL representation and build 
up the LIL representation. There are a number of aspects to 
this mapping: 

i. The identity of the intrinsic operation in HIL may be 
expressed by one or more arguments in LIL. Informa- 
tion in element (e) in the inline assembly descriptor 
table set forth above is used to generate code express- 
ing this identity in UL. 

ii. The implicit return value (if any) from HIL is expressed 
as an argument in UL. 

iii. Arguments of certain types in HIL must be translated 
to arguments of different types in UL. The translation 
utility for any given argument type must be hand- 
coded, although the correct translation utility is 
invoked automatically by the translation process for the 
intrinsic operation. 

iv. The serialization mask (if any) from HIL is a special 
attribute (not an argument) in UL. 

v. The UL arguments must be emitted in the correct order. 
Information in element (e) in the inline assembly 
descriptor table as set forth above describes how to take 
the identity arguments from (i), the return value argu- 
ment (if any) from (ii), and any other HIL arguments, 
and emit them into UL in the correct order. 

For each possible intrinsic operation, the tool run at 
compiler-build time creates a piece of CG that takes as input 
the HIL form of that intrinsic operation and generates the 
UL form of that intrinsic operation. 

In a preferred embodiment, the tool run at compiler-build 
time advantageously recognizes when two or more intrinsic 
operations are translated using the same algorithm, and 
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generates a single piece of code embodying that algorithm type or a new return type; in such a case it is likely that 

that can perform translations for all of those intrinsic opera- compiler stages and automation that processes the table will 

uons. When this happens, information on the identity of the have to be modified). Reducing the amount of code that must 

intrinsic operation described in (i) above is stored in the be written by hand makes it simpler and quicker to add 

same data structures described in A further above, so that the 5 SU pp 0 rt for new intrinsic operations, and reduces the possi- 

translauon code can handle the multiple intrinsic operations. bility of error wherj new mtrinsic operations. 

In the preferred embodiment, translauon algonthms for two A advaD tageous feature enabled by the present 

inmnsic operations are considered "the same" if all of the mvendon ^ uat key ^ routines ma / now F access 

°J? W1 fJ?r ? ' machine instruction-level code so as to optimize run-time 

Hie HIL forms of ^the operations have the same number of 10 performance. Performance^ritical library routines (e.g. 

arguments of the same types in the same order. mat h or graphics library routines) often require access to 

The HIL forms of the operations either both lack a return low-level machine instructions to achieve maximum perfor- 

value or have the same return type. mance on modern processors. In the current art, they are 

The identity information is expressed in the LIL forms of typically hand-coded in assembly language. 

• the operations using the same number of arguments of 15 As traditionally performed, hand-coding of assembly lan- 

the same types. guage has many drawbacks. It is inherently tedious, it 

The LIL arguments for the operations occur in the same requires detailed understanding of microarchitecture perfor- 

order. mance characteristics, it is difficult to do well and is error- 

In summary, within the internal program representations prone, the resultant code is hard to maintain, and, to achieve 

used by the compiler, the in lining of assembly instructions 20 optimal performance, the code requires rework for each new 

may be implemented as special calls in the HIL that the front implementation of the target architecture, 

end generates. Every assembly instruction supported by In a preferred embodiment of the present invention, 

inlining is defined as part of this intermediate language. performance-critical library routines may now be coded in 

When an in lined assembly instruction is encountered in high-level languages, using embedded machine instructions 

the source, after performing error checking, the FE would 25 as needed. Such routines may then be compiled into an 

emit, as part of the HIL, a call to the corresponding dedi- object file format that is amenable to cross-module optimi- 

cated HIL routine. zation and linking in conjunction with application code that 

The CG then replaces each such call in the HIL with the invokes the library routines. Specifically, the library routines 

corresponding machine instruction in the LIL which is then may be inlined at the call sites in the application program 

subject to optimizations by the LLO, without violating any 30 and optimized in the context of the surrounding code, 

associated serialization constraint specifiers (as discussed With reference to FIG. 7, intrinsics defined in "inline.h" 

above). system header file SH 2 enable machine instructions to be 

In addition to facilitating code generation from HIL to embedded, for example, in math library routine source code 

LIL, the table-driven approach advantageously assists code 702,. This "mathlib" source code 702, is then compiled in 

generation in other phases of the compiler. For example, and 35 accordance with the present invention into equivalent object 

with reference again to FIG. 1, the table could also be code 702 o . Meanwhile, source code 701, wishing to invoke 

extended to generate part of HLO 104 or LLO 107 for the functionality of "mathlib" is compiled into object code 

manipulating assembly intrinsics (or to generate libraries to 701 o in the traditional manner employed for cross-module 

be used by HLO 104 or LLO 107). This could be optimization. Cross-module optimization and linking 

accomplished, for instance, by having the table provide 40 resources 704 then combine the two object codes 701 o and 

semantic information on the intrinsics that indicates optimi- 702 o to create optimized executable code 705. 

zation freedom and optimization constraints. Although the In FIG. 7, it should be noted that the math library is 

greatest benefit comes from using the table for as many merely used as an example. There are other analogous 

compiler stages as possible, this approach applies equally high-performance libraries for which the present invention 

well to a situation in which only some of the compiler stages 45 brings programming advantages, e.g., for graphics, 

use the table — for example, where neither HLO 104 nor multimedia, etc. 

LLO 107 use the table. In addition to easing the programming burden on library 

Although the preferred embodiment does library Gen- writers, the ability to embed machine instructions into 

eration and Partial Code Generator Generation (as described source code spares the library writers from having to 

above) at compiler-build time, it would not be substantially 50 re-structure low-level hand-coded assembly routines for 

different for FE 102, CG 105, or some library to consult the each implementation of the target architecture, 

table (or some translated form of the table) at compiler-run Floating Point ("_fpreg") Data Type 

time instead. The description of a preferred embodiment has so far 

Furthermore, although this approach has been disclosed to centered on the inventive mechanism disclosed herein for 

apply to assembly intrinsics, it could equally well be applied 55 inlining machine instructions into the compilation and opti- 

to any set of operations where there is at least one compiler mization of source code. It will be appreciated that this 

stage that takes a set of operations in a regular form and mechanism will often be called upon to compile objects that 

translates them into another form, where the translation include floating-point data types. A new data type is also 

process can occur in a straightforward and automated fash- disclosed herein, named "_Jpreg" in the C programming 

60 language, which allows general programmatic access 

Each time a new intrinsic operation needs to be added to (including via the inventive machine instruction inlining 

the compiler, a new entry is added to the table of intrinsic mechanism) to the widest mode floating-point arithmetic 

operations. A compiler stage that relies on the table-driven supported by the processor. This data type corresponds to a 

approach usually need not be modified by hand in order to floating-point representation that is as wide as the floating- 

manipulate the new intrinsic operation (the exception is if 65 point registers of the underlying processor. It will be under- 

the language in which the table itself is written has to be stood that although discussion of the inventive data type 

extended — for example, to accommodate a new argument herein centers on "_rpreg'' as named for the C programming 
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language, the concepts and advantages of the inventive data 
type are applicable in other programming languages via 

corresponding data types given their own names. J 

Apre condition to fully enabling the "_fpreg" data type is 5 d - (a • b) + c; 

that the target processor must of course be able to support 

memory access instructions that can transfer data between 

its floating-point registers and memory without loss of range where the g! obal var j a ble d is assigned the result of the 

or precision. dot-product. For this example, according to the standard 

Depending on the characteristics of the underlying 10 "usual arithmetic conversion rule" of the C programming 

processor, the M __fpreg" data type may be defined as a data language, the floating-point multiplication and addition 

type that either requires "active" or "passive" conversion. expressions will be evaluated in the "double" data type using 

The distinction here is whether instructions are emitted double precision floating-point arithmetic instructions, 

when converting a value of "_fpreg" data type to or from a However, in order to exploit greater precision afforded by a 

value of another floating-point data type. In an active ^ pn)cessor ^ ^3^.^ ^ters whose width exceeds 

conversion, a machine instruction would be needed to effect ^ Qf ^ ^ ^ ^ 

the conversion whereas m a passive conversion, no machine 1t . . . , . , . 

tA t „ , , ... may alternatively be used as shown below: 
instruction would be needed. In either case, the memory 

representation of an object of "_fpreg" data type is defined double a, b, c, d; 

to be large enough to accommodate the full width of the 20 main ( ) 
floating-point registers of the underlying processor. 

The type promotion rules of the programming language 

are advantageously extended to accommodate the _JJpreg ^ 

data type in a natural way. For example, for the C program- 25 d = (CJpreg) a * b) + <r, 

ming language, it is useful to assert that binary operations } 
involving this type shall be subject to the following promo- 

tion rules. Note ^ var i aD le "a" of type double is "typecast" 

1. First, if either operand has type _fpreg, the other ^ into an _fpreg value. Hence, based on the previously 
operand is converted to _fpreg. mentioned extension to the usual arithmetic conversion rule, 

2. Otherwise, if either operand has type long double, the the variables "a", "b", and "c" of "double" type are con- 
other operand is converted to long double. verted (either passively or actively) into " fpreg" type 

3. Otherwise, if either operand has type double, the other values and both the multiplication and addition operations 
operand is converted to double. 35 wil1 operate in the maximum floating-point precision corre- 

Note that in setting the foregoing exemplary promotion sponding to the full width of the underlying floating-point 

rules, it is assumed that the _fpreg data type which corre- registers. In particular, the intermediate maximum precision 

sponds to the full floating-point register width of the target product of "a" and "b" will not need to be rounded prior to 

processor has greater range and precision than the long ^ being summed with "c". The net result is that a more 

double data type. If this is not the case, then the first two accurate dot-product value will be computed and round-off 

rules may need to be swapped in sequence. errors are limited to the final assignment to the variable "d". 

Note also that in general, assuming type _fpreg has Applying the foregoing features and advantages of the 

greater range and/or precision than type long double, it may _fp reg data type to the inventive mechanism disclosed 

be that the result of computations involving _ipreg values 45 her ein for inlining machine instructions, it will be seen that 

cannot be represented precisely as a value of type long me eteis ^ return values of inlrinsics ified in 

double. T*e behavior of me type conversion from _fpreg to accordance ^ that mechanism ^ to ^ of 

long double (or to any other source-level floating-point type) ... , . . . . . . . . ' . 4 „ . 

**u r u , Jf A c a u a- * thus data type when such mtnnsics correspond to floating 

must therefore be accounted for. A preferred embodiment instructions 

employs a similar rule to that used for conversions from 50 " 

double to float: If the value being converted is out of range, For example, in order to allow source-level embedding of 

the behavior is undefined; and if the value cannot be a floating-point fused-multiply add instruction: 
represented exactly, the result is either the nearest higher or 

the nearest lower representable value. &3 

It will be further appreciated that the application and 55 
availability of the _fpreg data type is not required to be mat tDe product of the values contained in 2 floating- 
universal within the programming language. Depending on point register source operands (frl and fr2) with the value 
processor architecture and programmer needs, it is possible contained in another floating-point register source operand 
to limit availability of the _fpreg data type to only a subset M (fr3), and writes the result to a floating-point register (fr4), 
of the operations that may be applied to other floating-point the following inline assembly intrinsic can be defined: 
types. 

To illustrate general programming use of this new data fr4=_fprcg _Asm_fma (__fpreg frl, _fpreg &2, _fpre g f>3) 
type, consider the following C source program that com- 
putes a floating-point 'dot-product* (a b-fc): fi5 Now> following the general programmatic example used 
double a, b, c, d; above, this intrinsic can be used to compute a floating-point 
main ( ) "dot-product" (a b+c) in a C source program as follows: 
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d - __Asm_fma (a, b, c); 



double a, b, c, d; Cbnclusion 

main ( ) It be further understood that the present invention 

may be embodied in software executable on a general 
purpose computer including a processing unit accessing a 
5 computer-readable storage medium, a memory, and a plu- 
rality of I/O devices. 
Although the present invention and its advantages have 

been described in detail, it should be understood that various 

changes, substitutions and alterations can be made herein 
where d is assigned the result of the floating-point compu- io without departing from the spirit and scope of the invention 
tation ((a*b)+c) as defined by the appended claims. 

Note that the arguments to _j\sm __fma (a, b, and c) are We claim: 
implicitly converted from type double to type _fpreg when 1 A mcthod for enablin g acccss M the C programming 
invoking the intrinsic, and that the intrinsic return value of language to the widest mode floating-point arithmetic sup- 
type _fpreg is implicitly converted to type double for 15 P orted bv a Processor, wherein the processor can transfer 



assignment to d. As discussed above, if type fpreg has 

greater range and/or precision than type double, it may be 
that the result of the intrinsic operation (or indeed any other 
expression of type _tpreg) cannot be represented precisely 
as a value of type double. The behavior of the type conver- 
sion from _Jpreg to double (or to any other source-level 
floating-point type, such as float) must therefore be 
accounted for. In a preferred embodiment, a similar rule is 
employed to that used for conversions from double to float: 
If the value being converted is out of range, the behavior is 
undefined; and if the value cannot be represented exactly, the 
result is either the nearest higher or nearest lower represent- 
able value. 

If the result of the dot-product were to be used in a 
subsequent floating-point operation, it would be possible to 
minimize loss of precision by carrying out that operation in 
type __fpreg as follows: 

double a, b, c, d, e, f, g; 
main ( ) 



{ 

_fpreg x, y, 

x - _Asm_fma (a, b, c); 
y - _^Asm_fma (e, f, g); 



} 



d - x + y; 
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Note that the results of the two dot-products are stored in 45 
variables of type _fpreg; the results are summed (still in 
type __fpreg), and this final sum is then converted to type 
double for assignment to d This should produce a more 
precise result than storing the dot-product results in vari- 
ables of type double before summing them. Also, note that 50 
the standard binary operator '+' is being applied to values of 
type __fjpreg to produce an _fpreg result (which, as previ- 
ously stated, must be converted to type double for assign- 
ment to d). 



data between memory and its floating-point registers without 
loss of range or precision, the method comprising the steps 

of: 

(a) defining ^fpreg" as a floating-point data type having 
a memory representation that has range and precision at 
least as great as said floating-point registers; 

(b) declaring selected operands to be of the floating-point 
data type, said selected operands specified in C source 
code on which floating-point arithmetic is to be 
performed, said selected operands including arguments 
and return values of inline assembly intrinsics used to 
embed floating-point instructions into the source code; 

(c) compiling the source code into corresponding object 
code; 

(d) executing the object code; 

(e) performing said floating-point arithmetic, said step (e) 
including the substep of transferring data between 
memory representations corresponding to said selected 
operands and said floating-point registers; and 

(f) converting data types according to type promotion 
rules when said floating-point arithmetic combines 

operands having different data types including fpreg, 

the promotion rules including hierarchical rules regard- 
ing conversion between data types to create data type 
compatibility between a pair of source operands, the 
promotion rules including, in order of precedence: 

(1) if one source operand is of data type _fpreg, 
convert the other source operand to data type 
-fpreg; 

(2) if one source operand is of data type long double, 
convert the other source operand to data type long 
double; and 

(3) if one source operand is of data type double, convert 
the other source operand to data type double; 

and wherein rule (2) takes precedence over rule (1) if the 
memory representation of a long double data type has 
greater range and precision than said floating-point registers. 
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The automatic production of syntax-organized compilers using a 
modified pushdown automaton to perform LL(1) parsing instead of recursive 
descent is investigated. The technique is similar to transition matrices, 
allowing very fast compilers , but considerably smaller. Unlike 
traditional LL(1) parsing, strings of input symbols are checked by one 
state instead of several, thereby reducing the number of states required. 
An integer value indicating how many input symbols to advance in a state 
transition is used instead of a Boolean value simply indicating if a symbol 
is consumed. Multiple error entries are also eliminated. 

In addition to generating the syntax analyzer automatically, 
semantics must be automatically incorporated into the compiler from some 
formal specification. The programming language PASCAL is investigated as a 
metalanguage for defining compiler -oriented semantics, including the 
use of semantic macros in PASCAL to define similar features for a variety 
of programming languages as a means of automating static semantics and 
intermediate code expressible in PASCAL to define dynamic semantics. The 
intermediate language is defined to serve for a variety of source languages 
and target machines. PASCAL is used to completely define the semantics of 
itself and considered for defining FORTRAN and ADA. Because PASCAL is a 
programming language instead of a mathematical formal notation, it is 
easier to use a semantic metalanguage but its main advantage is that a 
PASCAL definition of a language constitutes a compiler for that language. 

Algorithms were developed and implemented to generate LL(1) 
compiler tables from language specifications and to use the generated 
tables to compile source programs and it is shown how the pushdown 
automaton parsing technique can be extended to LL(k) parsing, for k > 1. A 
complete specification of PASCAL was used to generate a PASCAL compiler 
and syntactic specifications of FORTRAN and ADA were developed to generate 
parsing tables for these languages. These parsing tables are much smaller 
than parsing tables generated by other methods. The PASCAL compiler 
generated is comparable to a hand-coded recursive-descent compiler in 
terms of compilation time and contains significantly less source code. 
Therefore, an advantage is gained in both time and space in compilers 
generated by this technique. 



14/9/102 (Item 20 from file: 8) 

DIALOG (R) File 8:Ei Compendex(R) 

(c) 2006 Elsevier Eng. Info. Inc. All rts . reserv. 



00706644 E.I. Monthly No: EI7804023886 E.I. Yearly No: EI78015160 

Title: MARGOT: A MACRO -BASED GENERATOR OF COMMAND LANGUAGE 
INTERPRETERS . 
Author: Cashman, Paul M. ; Myszewski, Mathew J. 
Corporate Source: Mass Comput Assoc, Inc, Wakefield 

Source: Proc of the Digital Equip Comput Users Soc, v 3 n 4 1977, Boston, 
Mass, May 31-Jun 3 1977 Publ by Digital Equip Corp, Maynard, Mass, 1977 p 
1131-1144 

Publication Year: 1977 

Language : ENGL I SH 

Journal Announcement: 7804 

Abstract: MARGOT is a system consisting of a set of metalanguage 
operators which can be used to describe the syntax and semantics of command 
languages. The operators are implemented as macros which expand to 
produce operation codes for a 11 MARGOT machine. " The latter is implemented 
as an interpreter written in PDP-11 assembler language. MARGOT is 
designed to be a powerful, problem-oriented, easy -to-learn language which 
corresponds naturally to BNF and allows a command's syntax and semantics to 
be associated easily . MARGOT includes facilities for definition of 
syntactic and semantic constructs, iteration, and specification of input 
and syntactic choice. The assembly-time and run-time actions of the MARGOT 
system are presented. Experience of MARGOT users is discussed, and MARGOT' s 
advantages and shortcomings are analyzed. 21 refs. 

Descriptors: *COMPUTER OPERATING SYSTEMS- -*Program Interpreters 

Classification Codes: 

723 (Computer Software) 

72 (COMPUTERS & DATA PROCESSING) 
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(c) 2006 NTIS, Intl Cpyrght All Rights Res. All rts. reserv. 

0570627 NTIS Accession Number: AD-A029 055/l/XAB 
The Augment Precompiler . I. User Information 
(Technical summary rept) 
Crary, F. D. 

Wisconsin Univ Madison Mathematics Research Center 
Corp. Source Codes: 221200 
Report No.: MRC-TSR-1469 
Apr 76 14 9p 

Document Type: Translation 
Journal Announcement: GRAI7622 

Supersedes report dated Dec 74, AD-A006 542. See also AD-A020 198. 

Order this product from NTIS by: phone at 1-800 -553 -NTIS (U.S. 
customers); (703)605-6000 (other countries); fax at (703)321-8547; and 
email at orders@ntis.fedworld.gov. NTIS is located at 5285 Port Royal Road, 
Springfield, VA, 22161, USA. 

NTIS Prices: PC A07/MF A01 

Contract No.: DAAG2 9-75 -C-0024 

AUGMENT allows the easy use of packages implementing nonstandard 
data types and operations . This report describes the use of the 

precompiler , the preparation of supporting packages implementing 
nonstandard packages. Technical documentation is contained in a forthcoming 
companion report . (Author) 

Descriptors: *Compilers ; *Computer programming; Fortran; Programming 
manuals; Mathematical logic; Programming languages; Machine translation; 
High level languages; User needs; Digital computers 

Identifiers: * Precompilers ; Augment precompilers ; Nonstandard data 
type ; UNIVAC 1100 computers; Translations; NTISDODXA 

Section Headings: 62B (Computers, Control, and Information 
Theory- -Computer Software) 
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(c) 2006 NTIS, Intl Cpyrght All Rights Res. All rts . reserv. 

0572766 NTIS Accession Number: AD-A029 312/6/XAB 

Evaluation of HAL/ S Language Compilability Using SAMSO's Compiler 
Writing System (CWS) 
(Final rept . Mar 75-Feb 76) 

Feliciano, M. ; Anderson, H. D. ; Bond, J. W. 

Aerospace Corp El Segundo Calif Information Processing Div 

Corp. Source Codes: 409525 

Report No. : TR-0076 (6803) -1; SAMSO-TR- 76 - 13 7 
2 0 Aug 76 7 Op 

Journal Announcement: GRAI7623 

Order this product from NTIS by: phone at 1- 800 -553 -NTIS (U.S. 
customers); (703)605-6000 (other countries); fax at (703)321-8547; and 
email at orders@ntis.fedworld.gov. NTIS is located at 52 85 Port Royal Road, 
Springfield, VA, 22161, USA. 

NTIS Prices: PC A04/MF A01 

Contract No.: F04701-75-C-0076 

NASA/Langley is engaged in a program to develop an adaptable guidance and 
control software concept for spacecraft such as shuttle-launched payloads . 
It is envisioned that this flight software be written in a higher-order 
language, such as HAL/S, to facilitate changes or additions. To make this 
adaptable software transferable to various onboard computers, a compiler 
writing system capability is necessary. A joint program with the Air Force 
Space and Missile Systems Organization was initaiated to determine if the 
Compiler Writing System (CWS) owned by the Air Force could be utilized 
for this purpose. The present study explores the feasibility of including 
the HAL/S language constructs in CWS and the effort required to 
implement these constructs . This will determine the compilability of 
HAL/S using CWS and permit NASA/Langley to identify the HAL/S constructs 
desired for their applications. The study consisted of comparing the 
implementation of the Space Programming Language using CWS with the 
requirements for the implementation of HAL/S. It is the conclusion of the 
study that CWS already contains many of the language features of HAL/S and 
that it can be expanded for compiling part or all of HAL/S. It is assumed 
that persons reading and evaluating this report have a basic familiarity 
with (1) the principles of compiler construction and operation, and (2) 
the logical structure and applications characteristics of HAL/S and SPL. 
(Author) 

Descriptors: ^Compilers ; *Programming languages; *High level languages; 
♦Computer programming; Spacecraft; Space shuttles; Onboard; Computer 
programs; Computer program documentation; Payload 

Identifiers: *Compiler writing system; HAL/S programming language; 
Computer software; CDC -66 00 computers; Space programming language; 
NTISDODXA 

Section Headings: 62B (Computers, Control, and Information 
Theory- -Computer Software) 
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(c) 2006 Institution of Electrical Engineers. All rts . reserv. 

08467179 INSPEC Abstract Number: C2003-01-7440-055 
Title: Development of preprocessor program for articulated total body 
Author (s): Lee Dong Jea; Son Kwon; Jeon Kyunam; Choi Kyunghyun 
Author Affiliation: Pusan Nat. Univ., South Korea 

Conference Title: ICCAS 2002. International Conference on Control, 
Automation and Systems p. 2701-4 

Publisher: Inst. Control, Autom. & Syst . Eng, Taejon, South Korea 
Publication Date: 2 001 Country of Publication: South Korea CD-ROM pp. 
Material Identity Number: XX-2 001 - 01846 

Conference Title: Proceedings of 2001 International Conference on 
Control, Automation and Systems (16th Korea Automatic Control Conference) 

Conference Sponsor: Korea Res. Found.; Korea Sci . & Eng. Found.; Korea 
Nat. Tourism Organ.; Korean Federation of Sci. & Technol . Soc 

Conference Date: 17-21 Oct. 2001 Conference Location: Jeju Island, 
South Korea 

Language: Korean Document Type: Conference Paper (PA) 
Treatment: Applications (A); Practical (P) 

Abstract: Computer simulations are widely used to analyze passenger 
safety in traffic accidents. ATB (articulated total body) is a computer 
simulation model developed to predict gross human body response to such 
dynamic environments as vehicle crashes and pilot ejections. ATB, whose 
code is open, has high flexibility and application capability that users 
can easily insert defined modules and functions . ATB is, however, 

inconvenient as it was coded in FORTRAN and it needs a formated input file. 
Moreover, it takes much time to make input files and to modify coding 
errors. The study aims to increase user friendliness by adding a 
preprocessor program, WINATB (WINdow ATB) , to the conventional ATB. 
WINATB programmed in Visual C++ and OpenGL uses ATB IV as a dynamic solver. 
The preprocessor helps users prepare input files through graphic 
interface and dialog box and an additional postprocessor presents graphical 
presentation of simulated results. In the case of a frontal crash, the 
results obtained by WINATB and MADYMO are compared to validate the 
effectiveness of WINATB. (7 Refs) 
Subfile: C 

Descriptors: accidents; digital simulation; road vehicles; safety 

Identifiers: preprocessor program; articulated total body; computer 
simulations; passenger safety; traffic accidents; gross human body response 
; dynamic environments; vehicle crashes; pilot ejections; user friendliness 
; WINATB; OpenGL; Visual C++; ATB IV; dynamic solver; graphic interface; 
dialog box; graphical presentation; frontal crash; MADYMO 

Class Codes: C7440 (Civil and mechanical engineering computing) 

Copyright 2002, IEE 



Set Items Description 

51 3219344 (INSERT??? OR ADD??????? OR EMBED???? OR INCLUD??? OR INCL- 

US??? OR INTEGRAT??? OR IMPLEMENT????? OR AUGMENT????? OR UPD- 
AT? OR UP() (DATE? OR DATING? OR GRAD?) OR UPGRAD? OR GENERAT?- 
?? OR EXTEND??? OR EXTENS??? OR INCORPORAT? ?? ) (5N) (CONSTRUCT? 
? OR FUNCTION 

52 657350 PREPROCESSOR? ? OR PRE () PROCESSOR? ? OR PREPROCESSER? ? OR 

PRE () PROCESSER? ? OR PRAGMA OR DIRECTIVE OR METAPROGRAMM??? OR 
COMPILER? ? OR INTERPRETER? ? OR PRECOMPILER? ? OR PROBE 

53 10936287 EAS??? OR FACILITAT? ?? OR SIMPLIF? ?? ???? 

54 45929 SI AND S2 AND S3 

55 22762 ASL OR ADVANCED ( 2 W) CONFIGURATION ( 2 W) POWER ( 2 W) INTERFACE OR - 

ACPI OR AML 

56 147 S4 AND S5 

57 101 RD (unique items) 

58 60 S7 AND (PY<2003 OR PD<20021023) 

59 9880 S1(100N)S2 (100N)S3 

510 9 (S9 AND S5) NOT S8 

511 681 (S9 AND (PREPROCESSOR? ? OR PRE () PROCESSOR? ? OR PREPROCES- 

SER? ? OR PRE () PROCESSER? ? OR PRAGMA OR METAPROGRAMM??? OR C- 
OMPILER? ? OR INTERPRETER? ? OR PRECOMPILER? ? OR ADVANCED ( 2W- 
) CONFIGURATION (2W) POWER (2W) INTERFACE OR ACPI)/TI) NOT (S8 OR - 
S10) 

512 1464 S1(20N)S2(20N)S3 

513 198 (S12 AND (PREPROCESSOR? ? OR PRE () PROCESSOR? ? OR PREPROCE- 

SSER? ? OR PRE () PROCESSER? ? OR PRAGMA OR METAPROGRAMM??? OR - 
COMPILER? ? OR INTERPRETER? ? OR PRECOMPILER? ? OR ADVANCED (2- 
W) CONFIGURATION ( 2 W) POWER (2W) INTERFACE OR ACPI)/TI) NOT (S8 OR 
S10) 

514 547 SI (10N) S2 (10N) S3 

515 90 (S14 AND (PREPROCESSOR? ? OR PRE () PROCESSOR? ? OR PREPROCE- 

SSER? ? OR PRE () PROCESSER? ? OR PRAGMA OR METAPROGRAMM??? OR - 
COMPILER? ? OR INTERPRETER? ? OR PRECOMPILER? ? OR ADVANCED (2- 
W) CONFIGURATION (2W) POWER (2W) INTERFACE OR ACPI) /TI) NOT (S8 OR 
S10) 

516 55 RD (unique items) 

517 55 S16 AND (PY<2003 OR PD<20021023) 
? show files 

File 275: Gale Group Computer DB (TM) 1983 -2006/Aug 11 

(c) 2006 The Gale Group 
File 47:Gale Group Magazine DB (TM) 1959-2006/Aug 11 

ic) 2 006 The Gale group 
File 16:Gale Group PROMT (R) 1990 -2006/Aug 11 

(c) 2006 The Gale Group 
File 624 :McGraw-Hill Publications 1985-2006/Aug 14 

(c) 2006 McGraw-Hill Co. Inc 
File 484 : Periodical Abs Plustext 1986-2006/Aug Wl 

(c) 2006 ProQuest 
File 613 :PR Newswire 1999-2006/Aug 14 

(c) 2006 PR Newswire Association Inc 
File 813 :PR Newswire 1987-1999/Apr 30 

(c) 1999 PR Newswire Association Inc 
File 239:Mathsci 1940 -2006/Oct 

(c) 2006 American Mathematical Society 
File 370:Science 1996-1999/ Jul W3 

(c) 1999 AAAS V "H V 

File 696:DIALOG Telecom. Newsletters 1995-2006/Aug 12 r\)\X lUM 

(c) 2006 Dialog \\Qi 
File 621:Gale Group New Prod . Annou . (R) 1985-2 006/Aug 11 IM r ^ 

(c) 2 006 The Gale Group 
File 674: Computer News Fulltext 1989-2006/ Jul W5 



(c) 2006 IDG Communications 
File 88:Gale Group Business A.R.T.S. 1976 -2006/Aug 02 

(c) 2 006 The Gale Group 
File 369:New Scientist 1994 -2006/ Jul W3 

(c) 2006 Reed Business Information Ltd. 
File 160:Gale Group PROMT (R) 1972-1989 

(c) 1999 The Gale Group 
File 635:Business Dateline (R) 1985 -2006/Aug 12 

(c) 2006 ProQuest Inf o&Learning 
File 15 :ABI/ Inform (R) 1971 -2006/Aug 14 

(c) 2006 ProQuest Inf o&Learning 
File 9:Business & Industry (R) Jul/1994 -2006/Aug 11 

(c) 2 006 The Gale Group 
File 13:BAMP 2006/Aug Wl 

(c) 2 006 The Gale Group 
File 810:Business Wire 1986 - 1999/Feb 28 

(c) 1999 Business Wire 
File 610:Business Wire 1999-2006/Aug 14 

(c) 2006 Business Wire. 
File 647:CMP Computer Fulltext 1988-2006/Sep W4 

(c) 2006 CMP Media, LLC 
File 98:General Sci Abs 1984-2005/Jan 

(c) 2006 The HW Wilson Co. 
File 148:Gale Group Trade & Industry DB 1976-2006/Aug 11 

(c)2006 The Gale Group 
File 634: San Jose Mercury Jun 1985-2006/Aug 12 

(c) 2 006 San Jose Mercury News 
File 636:Gale Group Newsletter DB(TM) 1987 -2006/Aug 11 

(c) 20 06 The Gale Group 



562920 INSERT??? 

23105565 
793646 
25813235 
722723 
7258925 
4474273 
328491 
3428694 
19807682 
5427356 
213453 
3032119 
22882 
2162517 
6957223 
3773898 
3278454 
2701296 
604013 
4060748 
12547911 
25259351 
39840 
1780140 
2151103 
618 
19539 
2923136 
10537611 
7000203 
3931300 
10937 
2789534 
1165887 
533 
1642783 
51102 
13893239 
6666845 
643851 
3216617 
1005123 
259030 
2097199 
12908 
558874 
16654 
961414 
558874 
691 
190159 
1130031 
3432441 
SI 3219344 



ADD?? ???? ? 

EMBED???? 

INCLUD??? 

INCLUS??? 

INTEGRAT??? 

IMPLEMENT????? 

AUGMENT????? 

UPDAT? 

UP 

DATE? 

DATING? 

GRAD? 

UP(W) ((DATE? OR DATING?) OR GRAD?) 

UPGRAD? 

GENERAT??? 

EXTEND??? 

EXTENS??? 

INCORPORAT??? 

CONSTRUCT? ? 

FUNCTION? ? 

DATA 

TYPE? ? 

DATA (W) TYPE? ? 
LANGUAGE 
ELEMENT? ? 

LANGUAGE (W) ELEMENT? ? 

OPERAND? ? 

OPERATOR? ? 

OPERATION? ? 

CONTROL 

STRUCTURE? ? 

CONTROL (W) STRUCTURE? ? 

STRUCTURE 

DEFINITION? ? 

STRUCTURE (W) DEFINITION? ? 

SYMBOL? ? 

BOOLEAN? ? 

HIGH 

LEVEL 

HIGH (W) LEVEL 

USER 

FRIENDLY 

USER (W) FRIENDLY 

LANGUAGE? ? 

(HIGH (W) LEVEL OR USER (W) FRIENDLY) (W) LANGUAGE? ? 
ROUTINE? ? 
SUBROUTINE? ? 
SUB 

ROUTINE? ? 
SUB (W) ROUTINE? ? 
MACRO? ? 
LIMITATION? ? 
RULE? ? 

(INSERT??? OR ADD??????? OR EMBED???? OR INCLUD??? OR 
INCLUS??? OR INTEGRAT??? OR IMPLEMENT????? OR 
AUGMENT????? OR UPDAT? OR UP ( ) (DATE? OR DATING? OR GRAD?) 
OR UPGRAD? OR GENERAT??? OR EXTEND??? OR EXTENS??? OR 
INCORPORAT???) (5N) (CONSTRUCT? ? OR FUNCTION? ? OR 
DATA () TYPE? ? OR LANGUAGE () ELEMENT? ? OR OPERAND? ? OR 
OPERATOR? ? OR OPERATION? ? OR CONTROL () STRUCTURE? ? OR 



STRUCTURE {) DEFINITION? ? OR SYMBOL? ? OR BOOLEAN? ? OR 
(HIGH () LEVEL OR USER () FRIENDLY) () LANGUAGE? ? OR ROUTINE? 
? OR SUBROUTINE? ? OR SUB () ROUTINE? ? OR MACRO? ? OR 
LIMITATION? ? OR RULE? ?) 



Set Items Description 

51 475835 (INSERT??? OR ADD??????? OR EMBED???? OR INCLUD??? OR INCL- 

US??? OR INTEGRAT??? OR IMPLEMENT????? OR AUGMENT????? OR UPD- 
AT? OR UP() (DATE? OR DATING? OR GRAD?) OR UPGRAD? OR GENERAT?- 
?? OR EXTEND??? OR EXTENS??? OR- INCORPORAT??? ) (5N) (CONSTRUCT? 
? OR FUNCTION 

52 163373 PREPROCESSOR? ? OR PRE () PROCESSOR? ? OR PREPROCESSER? ? OR 

PRE() PROCESSER? ? OR PRAGMA OR DIRECTIVE OR METAPROGRAMM? ? ? OR 
COMPILER? ? OR INTERPRETER? ? OR PRECOMPILER? ? OR PROBE 



S3 


1111542 


EAS??? OR FACILITAT? ? ? OR SIMPLIF??????? 


S4 


57634 


SI AND S2 AND S3 


S5 


5439 


ASL OR ADVANCED (2W) CONFIGURATION (2W) POWER (2W) INTERFACE OR - 




ACPI OR AML 


S6 


1248 


S4 AND S5 


S7 


3 


S6 AND IC= (G06F-009/45 OR G06F-001/26) 


S8 


3152 


S1(100N)S2 (100N)S3 


S9 


37 


(S8 AND S5) NOT S7 


S10 


21 


S9 NOT PD= (2002023 :20060724) 


Sll 


61 


(S8 AND (PREPROCESSOR? ? OR PRE () PROCESSOR? ? OR PREPROCES- 



SER? ? OR PRE () PROCESSER? ? OR PRAGMA OR METAPROGRAMM??? OR C- 
OMPILER? ? OR INTERPRETER? ? OR PRECOMPILER? ? OR ADVANCED (2W- 
) CONFIGURATION ( 2 W) POWER (2W) INTERFACE OR ACPI) /TI) NOT (S7 OR - 
S10) 

S12 36 Sll NOT PD= (2002023 :20060724) 

? show files 

File 348:EUROPEAN PATENTS 1978-2006/ 200632 

(c) 2006 European Patent Office 
File 349:PCT FULLTEXT 1979-2006/UB=20060803 , UT=20060727 

(c) 2006 WIPO/Univentio 



fun te*r 



591995 INSERT??? 

1204855 ADD??????? 

143035 EMBED???? 

1519591 INCLUD??? 

163854 INCLUS??? 

413 634 INTEGRAT??? 

375521 IMPLEMENT????? 

186165 AUGMENT????? 

138060 UPDAT? 

1149023 UP 

2217433 DATE? 

1954 DATING? 

309005 GRAD? 

1966 UP(W) ((DATE? OR DATING?) OR GRAD?) 

23915 UPGRAD? 

905125 GENERAT??? 

855565 EXTEND??? 

300431 EXTENS??? 

801812 INCORPORAT ? ? ? 

135209 CONSTRUCT? ? 

94184 8 FUNCTION? ? 

730144 DATA 

1373622 TYPE? ? 

14423 DATA (W) TYPE? ? 

77518 LANGUAGE 

1130270 ELEMENT? ? 

284 LANGUAGE (W) ELEMENT? ? 

7809 OPERAND? ? 

2 02127 OPERATOR? ? 

1010580 OPERATION? ? 

103 8 063 CONTROL 

980343 STRUCTURE? ? 

3857 CONTROL (W) STRUCTURE? ? 

896211 STRUCTURE 

220416 DEFINITION? ? 

545 STRUCTURE (W) DEFINITION? ? 

168520 SYMBOL? ? 

10004 BOOLEAN? ? 

1220936 HIGH 

741660 LEVEL 

107931 HIGH (W) LEVEL 

393225 USER 

2 6249 FRIENDLY 

10630 USER(W) FRIENDLY 

81562 LANGUAGE? ? 

2158 (HIGH (W) LEVEL OR USER (W) FRIENDLY) (W) LANGUAGE? ? 

132 823 ROUTINE? ? 

14107 SUBROUTINE? ? 

452466 SUB 

132823 ROUTINE? ? 

2456 SUB (W) ROUTINE? ? 

2 914 7 MACRO? ? 

338188 LIMITATION? ? 

176353 RULE? ? 

475 83 5 (INSERT??? OR ADD??????? OR EMBED???? OR INCLUD??? OR 
INCLUS??? OR INTEGRAT??? OR IMPLEMENT????? OR 
AUGMENT????? OR UPDAT? OR UP ( ) (DATE? OR DATING? OR GRAD 
OR UPGRAD? OR GENERAT??? OR EXTEND??? OR EXTENS??? OR 
INCORPORAT???) (5N) (CONSTRUCT? ? OR FUNCTION? ? OR 
DATA () TYPE? ? OR LANGUAGE () ELEMENT? ? OR OPERAND? ? OR 
OPERATOR? ? OR OPERATION? ? OR CONTROL () STRUCTURE? ? OR 



STRUCTURE () DEFINITION? ? OR SYMBOL? ? OR BOOLEAN? ? OR 
(HIGH () LEVEL OR USER () FRIENDLY) () LANGUAGE? ? OR ROUTINE? 
? OR SUBROUTINE? ? OR SUB () ROUTINE? ? OR MACRO? ? OR 
LIMITATION? ? OR RULE? ?) 



